* [PATCH v4 0/2] drivers/qcom: add Command DB support @ 2018-02-26 17:58 Lina Iyer 2018-02-26 17:58 ` [PATCH v4 1/2] drivers: qcom: add command DB driver Lina Iyer 2018-02-26 17:58 ` [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs Lina Iyer 0 siblings, 2 replies; 16+ messages in thread From: Lina Iyer @ 2018-02-26 17:58 UTC (permalink / raw) To: andy.gross, david.brown, linux-arm-msm, linux-soc Cc: rnayak, bjorn.andersson, linux-kernel, Lina Iyer Changes in v3: - DT binding documentation fixes as suggested by Rob. These patches add support for reading a shared memory database in the newer QCOM SoCs called Command DB. With the new architecture on SDM845, shared resources like clocks, regulators etc., have dynamic properties. These properties may change based on external components, board configurations or available feature set. A remote processor detects these parameters and fills up the database with the resource and available state information. Platform drivers that need these shared resources will need to query this database to get the address and properties and vote for the state. The information in the database is static. The database is read-only memory location that is available for Linux. A pre-defined string is used as a key into an entry in the database. Generally, platform drivers query the database only at init to get the information they need. [v1]: https://www.spinics.net/lists/linux-arm-msm/msg32462.html [v2]: https://lkml.org/lkml/2018/2/8/588 [v3]: https://lkml.org/lkml/2018/2/16/842 Lina Iyer (2): drivers: qcom: add command DB driver dt-bindings: introduce Command DB for QCOM SoCs .../devicetree/bindings/arm/msm/cmd-db.txt | 38 +++ drivers/of/platform.c | 1 + drivers/soc/qcom/Kconfig | 9 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/cmd-db.c | 319 +++++++++++++++++++++ include/soc/qcom/cmd-db.h | 50 ++++ 6 files changed, 418 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/msm/cmd-db.txt create mode 100644 drivers/soc/qcom/cmd-db.c create mode 100644 include/soc/qcom/cmd-db.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v4 1/2] drivers: qcom: add command DB driver 2018-02-26 17:58 [PATCH v4 0/2] drivers/qcom: add Command DB support Lina Iyer @ 2018-02-26 17:58 ` Lina Iyer 2018-03-05 18:42 ` Stephen Boyd 2018-02-26 17:58 ` [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs Lina Iyer 1 sibling, 1 reply; 16+ messages in thread From: Lina Iyer @ 2018-02-26 17:58 UTC (permalink / raw) To: andy.gross, david.brown, linux-arm-msm, linux-soc Cc: rnayak, bjorn.andersson, linux-kernel, Lina Iyer, Mahesh Sivasubramanian From: Mahesh Sivasubramanian <msivasub@codeaurora.org> Command DB is a simple database in the shared memory of QCOM SoCs, that provides information regarding shared resources. Some shared resources in the SoC have properties that are probed dynamically at boot by the remote processor. The information pertaining to the SoC and the platform are made available in the shared memory. Drivers can query this information using predefined strings. Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> Signed-off-by: Lina Iyer <ilina@codeaurora.org> --- drivers/of/platform.c | 1 + drivers/soc/qcom/Kconfig | 9 ++ drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/cmd-db.c | 319 ++++++++++++++++++++++++++++++++++++++++++++++ include/soc/qcom/cmd-db.h | 50 ++++++++ 5 files changed, 380 insertions(+) create mode 100644 drivers/soc/qcom/cmd-db.c create mode 100644 include/soc/qcom/cmd-db.h diff --git a/drivers/of/platform.c b/drivers/of/platform.c index c00d81dfac0b..26fb43847f4b 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -494,6 +494,7 @@ EXPORT_SYMBOL_GPL(of_platform_default_populate); #ifndef CONFIG_PPC static const struct of_device_id reserved_mem_matches[] = { { .compatible = "qcom,rmtfs-mem" }, + { .compatible = "qcom,cmd-db" }, { .compatible = "ramoops" }, {} }; diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index e050eb83341d..b12868a2b92d 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -3,6 +3,15 @@ # menu "Qualcomm SoC drivers" +config QCOM_COMMAND_DB + bool "Qualcomm Command DB" + depends on (ARCH_QCOM && OF) || COMPILE_TEST + help + Command DB queries shared memory by key string for shared system + resources. Platform drivers that require to set state of a shared + resource on a RPM-hardened platform must use this database to get + SoC specific identifier and information for the shared resources. + config QCOM_GLINK_SSR tristate "Qualcomm Glink SSR driver" depends on RPMSG diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile index dcebf2814e6d..bbd1230fc441 100644 --- a/drivers/soc/qcom/Makefile +++ b/drivers/soc/qcom/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o obj-$(CONFIG_QCOM_GLINK_SSR) += glink_ssr.o obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c new file mode 100644 index 000000000000..0792a2a98fc9 --- /dev/null +++ b/drivers/soc/qcom/cmd-db.c @@ -0,0 +1,319 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. */ + +#include <linux/kernel.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/of_platform.h> +#include <linux/of_reserved_mem.h> +#include <linux/platform_device.h> +#include <linux/types.h> + +#include <soc/qcom/cmd-db.h> + +#define NUM_PRIORITY 2 +#define MAX_SLV_ID 8 +#define CMD_DB_MAGIC 0x0C0330DBUL +#define SLAVE_ID_MASK 0x7 +#define SLAVE_ID_SHIFT 16 + +#define ENTRY_HEADER(hdr) ((void *)cmd_db_header + \ + sizeof(*cmd_db_header) + \ + hdr->header_offset) + +#define RSC_OFFSET(hdr, ent) ((void *)cmd_db_header + \ + sizeof(*cmd_db_header) + \ + hdr.data_offset + ent.offset) + +/** + * entry_header: header for each entry in cmddb + * + * @id: resource's identifier + * @priority: unused + * @addr: the address of the resource + * @len: length of the data + * @offset: offset at which data starts + */ +struct entry_header { + u64 id; + u32 priority[NUM_PRIORITY]; + u32 addr; + u16 len; + u16 offset; +}; + +/** + * rsc_hdr: resource header information + * + * @slv_id: id for the resource + * @header_offset: Entry header offset from data + * @data_offset: Entry offset for data location + * @cnt: number of entries for HW type + * @version: MSB is major, LSB is minor + */ +struct rsc_hdr { + u16 slv_id; + u16 header_offset; + u16 data_offset; + u16 cnt; + u16 version; + u16 reserved[3]; +}; + +/** + * cmd_db_header: The DB header information + * + * @version: The cmd db version + * @magic_number: constant expected in the database + * @header: array of resources + * @check_sum: check sum for the header. Unused. + * @reserved: reserved memory + * @data: driver specific data + */ +struct cmd_db_header { + u32 version; + u32 magic_num; + struct rsc_hdr header[MAX_SLV_ID]; + u32 check_sum; + u32 reserved; + u8 data[]; +}; + +/** + * DOC: Description of the Command DB database. + * + * At the start of the command DB memory is the cmd_db_header structure. + * The cmd_db_header holds the version, checksum, magic key as well as an + * array for header for each slave (depicted by the rsc_header). Each h/w + * based accelerator is a 'slave' (shared resource) and has slave id indicating + * the type of accelerator. The rsc_header is the header for such individual + * slaves of a given type. The entries for each of these slaves begin at the + * rsc_hdr.header_offset. In addition each slave could have auxiliary data + * that may be needed by the driver. The data for the slave starts at the + * entry_header.offset to the location pointed to by the rsc_hdr.data_offset. + * + * Drivers have a stringified key to a slave/resource. They can query the slave + * information and get the slave id and the auxiliary data and the length of the + * data. Using this information, they can format the request to be sent to the + * h/w accelerator and request a resource state. + */ + +static struct cmd_db_header *cmd_db_header; + +/** + * cmd_db_ready - Indicates if command DB is available + * + * Return: 0 on success, errno otherwise + */ +int cmd_db_ready(void) +{ + if (cmd_db_header == NULL) + return -EPROBE_DEFER; + else if (cmd_db_header->magic_num != CMD_DB_MAGIC) + return -EINVAL; + else + return 0; +} +EXPORT_SYMBOL(cmd_db_ready); + +static u64 cmd_db_get_u64_id(const char *id) +{ + u64 rsc_id = 0; + u8 *ch = (u8 *)&rsc_id; + int i; + + for (i = 0; i < sizeof(rsc_id) && id[i]; i++) + ch[i] = id[i]; + + return rsc_id; +} + +static int cmd_db_get_header(u64 query, struct entry_header *eh, + struct rsc_hdr *rh) +{ + struct rsc_hdr *rsc_hdr; + struct entry_header *ent; + int ret, i, j; + + ret = cmd_db_ready(); + if (ret) + return ret; + + if (!eh || !rh) + return -EINVAL; + + for (i = 0; i < MAX_SLV_ID; i++) { + rsc_hdr = &cmd_db_header->header[i]; + if (!rsc_hdr->slv_id) + break; + + ent = ENTRY_HEADER(rsc_hdr); + for (j = 0; j < rsc_hdr->cnt; j++, ent++) { + if (ent->id == query) + break; + } + + if (j < rsc_hdr->cnt) { + memcpy(eh, ent, sizeof(*ent)); + memcpy(rh, rsc_hdr, sizeof(*rh)); + return 0; + } + } + + return -ENODEV; +} + +static int cmd_db_get_header_by_rsc_id(const char *id, + struct entry_header *ent_hdr, + struct rsc_hdr *rsc_hdr) +{ + u64 rsc_id = cmd_db_get_u64_id(id); + + return cmd_db_get_header(rsc_id, ent_hdr, rsc_hdr); +} + +/** + * cmd_db_read_addr() - Query command db for resource id address. + * + * @id: resource id to query for address + * + * This is used to retrieve resource address based on resource + * id. + * Return: resource address on success, 0 on error + */ +u32 cmd_db_read_addr(const char *id) +{ + int ret; + struct entry_header ent; + struct rsc_hdr rsc_hdr; + + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); + + return ret < 0 ? 0 : ent.addr; +} +EXPORT_SYMBOL(cmd_db_read_addr); + +/** + * cmd_db_read_aux_data() - Query command db for aux data. + * + * @id : Resource to retrieve AUX Data on. + * @data : Data buffer to copy returned aux data to. Returns size on NULL + * @len : Caller provides size of data buffer passed in. + * + * Return: size of data on success, errno on error + */ +int cmd_db_read_aux_data(const char *id, u8 *data, int len) +{ + int ret; + struct entry_header ent; + struct rsc_hdr rsc_hdr; + + if (!data) + return -EINVAL; + + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); + if (ret) + return ret; + + if (len < ent.len) + return -EINVAL; + + len = min_t(u16, ent.len, len); + memcpy(data, RSC_OFFSET(rsc_hdr, ent), len); + + return len; +} +EXPORT_SYMBOL(cmd_db_read_aux_data); + +/** + * cmd_db_read_aux_data_len - Get the length of the auxllary data stored in DB. + * + * @id: Resource to retrieve AUX Data. + * + * Return: size on success, 0 on error + */ +size_t cmd_db_read_aux_data_len(const char *id) +{ + int ret; + struct entry_header ent; + struct rsc_hdr rsc_hdr; + + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); + + return ret < 0 ? 0 : ent.len; +} +EXPORT_SYMBOL(cmd_db_read_aux_data_len); + +/** + * cmd_db_read_slave_id - Get the slave ID for a given resource address + * + * @id: Resource id to query the DB for version + * + * Return: cmd_db_hw_type enum on success, CMD_DB_HW_INVALID on error + */ +enum cmd_db_hw_type cmd_db_read_slave_id(const char *id) +{ + int ret; + struct entry_header ent; + struct rsc_hdr rsc_hdr; + + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); + + return ret < 0 ? CMD_DB_HW_INVALID : + (ent.addr >> SLAVE_ID_SHIFT) & SLAVE_ID_MASK; +} +EXPORT_SYMBOL(cmd_db_read_slave_id); + +static int cmd_db_dev_probe(struct platform_device *pdev) +{ + struct reserved_mem *rmem; + void *dict, *start_addr; + int ret = 0; + + rmem = of_reserved_mem_lookup(pdev->dev.of_node); + if (!rmem) { + dev_err(&pdev->dev, "failed to acquire memory region\n"); + return -EINVAL; + } + + dict = devm_memremap(&pdev->dev, rmem->base, rmem->size, MEMREMAP_WB); + if (IS_ERR(dict)) + return -ENOMEM; + + start_addr = memremap(readl_relaxed(dict), readl_relaxed(dict + 0x4), + MEMREMAP_WB); + if (IS_ERR_OR_NULL(start_addr)) { + ret = PTR_ERR(start_addr); + goto done; + } + + cmd_db_header = start_addr; + if (cmd_db_header->magic_num != CMD_DB_MAGIC) { + ret = -EINVAL; + dev_err(&pdev->dev, "Invalid Command DB Magic\n"); + goto done; + } + +done: + devm_memunmap(&pdev->dev, dict); + return ret; +} + +static const struct of_device_id cmd_db_match_table[] = { + { .compatible = "qcom,cmd-db" }, + { }, +}; + +static struct platform_driver cmd_db_dev_driver = { + .probe = cmd_db_dev_probe, + .driver = { + .name = "cmd-db", + .of_match_table = cmd_db_match_table, + }, +}; + +static int __init cmd_db_device_init(void) +{ + return platform_driver_register(&cmd_db_dev_driver); +} +arch_initcall(cmd_db_device_init); diff --git a/include/soc/qcom/cmd-db.h b/include/soc/qcom/cmd-db.h new file mode 100644 index 000000000000..483d09ea1689 --- /dev/null +++ b/include/soc/qcom/cmd-db.h @@ -0,0 +1,50 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. */ + +#ifndef __QCOM_COMMAND_DB_H__ +#define __QCOM_COMMAND_DB_H__ + + +enum cmd_db_hw_type { + CMD_DB_HW_INVALID = 0, + CMD_DB_HW_MIN = 3, + CMD_DB_HW_ARC = CMD_DB_HW_MIN, + CMD_DB_HW_VRM = 4, + CMD_DB_HW_BCM = 5, + CMD_DB_HW_MAX = CMD_DB_HW_BCM, + CMD_DB_HW_ALL = 0xff, +}; + +#if IS_ENABLED(CONFIG_QCOM_COMMAND_DB) +u32 cmd_db_read_addr(const char *resource_id); +int cmd_db_read_aux_data(const char *resource_id, u8 *data, int len); +size_t cmd_db_read_aux_data_len(const char *resource_id); +enum cmd_db_hw_type cmd_db_read_slave_id(const char *resource_id); +int cmd_db_ready(void); +#else + +static inline u32 cmd_db_read_addr(const char *resource_id) +{ + return 0; +} +static inline int cmd_db_read_aux_data(const char *resource_id, u8 *data, + int len) +{ + return -ENODEV; +} +static inline size_t cmd_db_read_aux_data_len(const char *resource_id) +{ + return -ENODEV; +} + +static inline enum cmd_db_hw_type cmd_db_read_slave_id(const char *resource_id) +{ + return -ENODEV; +} +static inline int cmd_db_ready(void) +{ + return -ENODEV; +} + +#endif /* CONFIG_QCOM_COMMAND_DB */ +#endif /* __QCOM_COMMAND_DB_H__ */ -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/2] drivers: qcom: add command DB driver 2018-02-26 17:58 ` [PATCH v4 1/2] drivers: qcom: add command DB driver Lina Iyer @ 2018-03-05 18:42 ` Stephen Boyd 2018-03-06 16:21 ` Lina Iyer 0 siblings, 1 reply; 16+ messages in thread From: Stephen Boyd @ 2018-03-05 18:42 UTC (permalink / raw) To: Lina Iyer, andy.gross, david.brown, linux-arm-msm, linux-soc Cc: rnayak, bjorn.andersson, linux-kernel, Lina Iyer, Mahesh Sivasubramanian Quoting Lina Iyer (2018-02-26 09:58:01) > diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c > new file mode 100644 > index 000000000000..0792a2a98fc9 > --- /dev/null > +++ b/drivers/soc/qcom/cmd-db.c > @@ -0,0 +1,319 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. */ > + > +#include <linux/kernel.h> > +#include <linux/of.h> > +#include <linux/of_address.h> > +#include <linux/of_platform.h> > +#include <linux/of_reserved_mem.h> > +#include <linux/platform_device.h> > +#include <linux/types.h> > + > +#include <soc/qcom/cmd-db.h> > + > +#define NUM_PRIORITY 2 > +#define MAX_SLV_ID 8 > +#define CMD_DB_MAGIC 0x0C0330DBUL Make this an array so it's endian safe. > +#define SLAVE_ID_MASK 0x7 > +#define SLAVE_ID_SHIFT 16 > + > +#define ENTRY_HEADER(hdr) ((void *)cmd_db_header + \ > + sizeof(*cmd_db_header) + \ > + hdr->header_offset) > + > +#define RSC_OFFSET(hdr, ent) ((void *)cmd_db_header + \ > + sizeof(*cmd_db_header) + \ > + hdr.data_offset + ent.offset) > + > +/** > + * entry_header: header for each entry in cmddb struct entry_header - header for each... > + * > + * @id: resource's identifier > + * @priority: unused > + * @addr: the address of the resource > + * @len: length of the data > + * @offset: offset at which data starts offset from this entry header at which data starts? Or offset from where? > + */ > +struct entry_header { > + u64 id; > + u32 priority[NUM_PRIORITY]; > + u32 addr; > + u16 len; > + u16 offset; > +}; > + > +/** > + * rsc_hdr: resource header information ditto. > + * > + * @slv_id: id for the resource > + * @header_offset: Entry header offset from data > + * @data_offset: Entry offset for data location Same question: offset from where? > + * @cnt: number of entries for HW type > + * @version: MSB is major, LSB is minor @reserved: reserved for future use > + */ > +struct rsc_hdr { > + u16 slv_id; > + u16 header_offset; > + u16 data_offset; > + u16 cnt; > + u16 version; > + u16 reserved[3]; > +}; > + > +/** > + * cmd_db_header: The DB header information > + * > + * @version: The cmd db version > + * @magic_number: constant expected in the database > + * @header: array of resources > + * @check_sum: check sum for the header. Unused. > + * @reserved: reserved memory > + * @data: driver specific data > + */ > +struct cmd_db_header { > + u32 version; > + u32 magic_num; > + struct rsc_hdr header[MAX_SLV_ID]; > + u32 check_sum; Drop underscore? 'checksum' is usually one word. > + u32 reserved; > + u8 data[]; > +}; > + > +/** > + * DOC: Description of the Command DB database. > + * > + * At the start of the command DB memory is the cmd_db_header structure. > + * The cmd_db_header holds the version, checksum, magic key as well as an > + * array for header for each slave (depicted by the rsc_header). Each h/w > + * based accelerator is a 'slave' (shared resource) and has slave id indicating > + * the type of accelerator. The rsc_header is the header for such individual > + * slaves of a given type. The entries for each of these slaves begin at the > + * rsc_hdr.header_offset. In addition each slave could have auxiliary data > + * that may be needed by the driver. The data for the slave starts at the > + * entry_header.offset to the location pointed to by the rsc_hdr.data_offset. > + * > + * Drivers have a stringified key to a slave/resource. They can query the slave > + * information and get the slave id and the auxiliary data and the length of the > + * data. Using this information, they can format the request to be sent to the > + * h/w accelerator and request a resource state. > + */ > + > +static struct cmd_db_header *cmd_db_header; > + > +/** > + * cmd_db_ready - Indicates if command DB is available > + * > + * Return: 0 on success, errno otherwise > + */ > +int cmd_db_ready(void) > +{ > + if (cmd_db_header == NULL) > + return -EPROBE_DEFER; > + else if (cmd_db_header->magic_num != CMD_DB_MAGIC) > + return -EINVAL; > + else > + return 0; Drop else and just return 0. > +} > +EXPORT_SYMBOL(cmd_db_ready); > + > +static u64 cmd_db_get_u64_id(const char *id) > +{ > + u64 rsc_id = 0; > + u8 *ch = (u8 *)&rsc_id; > + int i; > + > + for (i = 0; i < sizeof(rsc_id) && id[i]; i++) > + ch[i] = id[i]; This could be a strncpy now? Didn't I already ask this? I'll have to look back at the other emails it seems. Actually, it looks like a cast of a string to an integer, which is then reversed to look up the same string. Not sure what the use is for this. > + > + return rsc_id; > +} > + > +static int cmd_db_get_header(u64 query, struct entry_header *eh, > + struct rsc_hdr *rh) > +{ > + struct rsc_hdr *rsc_hdr; > + struct entry_header *ent; > + int ret, i, j; > + > + ret = cmd_db_ready(); > + if (ret) > + return ret; > + > + if (!eh || !rh) > + return -EINVAL; > + > + for (i = 0; i < MAX_SLV_ID; i++) { > + rsc_hdr = &cmd_db_header->header[i]; > + if (!rsc_hdr->slv_id) > + break; > + > + ent = ENTRY_HEADER(rsc_hdr); > + for (j = 0; j < rsc_hdr->cnt; j++, ent++) { > + if (ent->id == query) > + break; > + } > + > + if (j < rsc_hdr->cnt) { > + memcpy(eh, ent, sizeof(*ent)); > + memcpy(rh, rsc_hdr, sizeof(*rh)); I suppose it's OK to punt on the endian issues for now if it's too hard. Eventually we'll want to handle it though and it shouldn't make the code any worse when endianness is the same. Can it be done now? > + return 0; > + } > + } > + > + return -ENODEV; > +} > + > +static int cmd_db_get_header_by_rsc_id(const char *id, > + struct entry_header *ent_hdr, > + struct rsc_hdr *rsc_hdr) > +{ > + u64 rsc_id = cmd_db_get_u64_id(id); > + > + return cmd_db_get_header(rsc_id, ent_hdr, rsc_hdr); > +} > + > +/** > + * cmd_db_read_addr() - Query command db for resource id address. > + * > + * @id: resource id to query for address > + * > + * This is used to retrieve resource address based on resource > + * id. > + * Return: resource address on success, 0 on error Weird spaces here. Mix of tabs and spaces perhaps? > + */ > +u32 cmd_db_read_addr(const char *id) > +{ > + int ret; > + struct entry_header ent; > + struct rsc_hdr rsc_hdr; > + > + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); > + > + return ret < 0 ? 0 : ent.addr; > +} > +EXPORT_SYMBOL(cmd_db_read_addr); > + > +/** > + * cmd_db_read_aux_data() - Query command db for aux data. > + * > + * @id : Resource to retrieve AUX Data on. > + * @data : Data buffer to copy returned aux data to. Returns size on NULL > + * @len : Caller provides size of data buffer passed in. Attach the ':' to the variable please. > + * > + * Return: size of data on success, errno on error success, -EINVAL on error > + */ > +int cmd_db_read_aux_data(const char *id, u8 *data, int len) > +{ > + int ret; > + struct entry_header ent; > + struct rsc_hdr rsc_hdr; > + > + if (!data) > + return -EINVAL; > + > + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); > + if (ret) > + return ret; > + > + if (len < ent.len) > + return -EINVAL; > + > + len = min_t(u16, ent.len, len); > + memcpy(data, RSC_OFFSET(rsc_hdr, ent), len); > + > + return len; > +} > +EXPORT_SYMBOL(cmd_db_read_aux_data); > + > +/** > + * cmd_db_read_aux_data_len - Get the length of the auxllary data stored in DB. > + * > + * @id: Resource to retrieve AUX Data. > + * > + * Return: size on success, 0 on error > + */ > +size_t cmd_db_read_aux_data_len(const char *id) > +{ > + int ret; > + struct entry_header ent; > + struct rsc_hdr rsc_hdr; > + > + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); A bunch of code is calling this function. Why not change the user interface to use an opaque 'resource' cookie that we can 'get' or 'find' and then use that cookie in the rest of the API to pull out the data that's desired? > + > + return ret < 0 ? 0 : ent.len; > +} > +EXPORT_SYMBOL(cmd_db_read_aux_data_len); > + > +/** > + * cmd_db_read_slave_id - Get the slave ID for a given resource address > + * > + * @id: Resource id to query the DB for version > + * > + * Return: cmd_db_hw_type enum on success, CMD_DB_HW_INVALID on error > + */ > +enum cmd_db_hw_type cmd_db_read_slave_id(const char *id) > +{ > + int ret; > + struct entry_header ent; > + struct rsc_hdr rsc_hdr; > + > + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); > + > + return ret < 0 ? CMD_DB_HW_INVALID : > + (ent.addr >> SLAVE_ID_SHIFT) & SLAVE_ID_MASK; > +} > +EXPORT_SYMBOL(cmd_db_read_slave_id); > + > +static int cmd_db_dev_probe(struct platform_device *pdev) > +{ > + struct reserved_mem *rmem; > + void *dict, *start_addr; > + int ret = 0; > + > + rmem = of_reserved_mem_lookup(pdev->dev.of_node); > + if (!rmem) { > + dev_err(&pdev->dev, "failed to acquire memory region\n"); > + return -EINVAL; > + } > + > + dict = devm_memremap(&pdev->dev, rmem->base, rmem->size, MEMREMAP_WB); > + if (IS_ERR(dict)) > + return -ENOMEM; > + > + start_addr = memremap(readl_relaxed(dict), readl_relaxed(dict + 0x4), > + MEMREMAP_WB); > + if (IS_ERR_OR_NULL(start_addr)) { Should just be !start_addr? I don't see where memremap() returns an error pointer. > + ret = PTR_ERR(start_addr); > + goto done; > + } > + > + cmd_db_header = start_addr; > + if (cmd_db_header->magic_num != CMD_DB_MAGIC) { memcmp? > + ret = -EINVAL; > + dev_err(&pdev->dev, "Invalid Command DB Magic\n"); > + goto done; > + } > + > +done: > + devm_memunmap(&pdev->dev, dict); I'm lost why we use devm_*() for this mapping. > + return ret; > +} > + > +static const struct of_device_id cmd_db_match_table[] = { > + { .compatible = "qcom,cmd-db" }, > + { }, > +}; > + > +static struct platform_driver cmd_db_dev_driver = { > + .probe = cmd_db_dev_probe, > + .driver = { > + .name = "cmd-db", > + .of_match_table = cmd_db_match_table, Add suppress_bind_attrs here to make sure we can't remove this device later? That also allows us to ignore unmapping the start_addr pointer in any sort of 'remove' function. > + }, > +}; > + ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/2] drivers: qcom: add command DB driver 2018-03-05 18:42 ` Stephen Boyd @ 2018-03-06 16:21 ` Lina Iyer 2018-03-06 16:56 ` Lina Iyer 2018-03-06 22:08 ` Stephen Boyd 0 siblings, 2 replies; 16+ messages in thread From: Lina Iyer @ 2018-03-06 16:21 UTC (permalink / raw) To: Stephen Boyd Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, bjorn.andersson, linux-kernel, Mahesh Sivasubramanian On Mon, Mar 05 2018 at 11:42 -0700, Stephen Boyd wrote: >Quoting Lina Iyer (2018-02-26 09:58:01) >> diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c >> new file mode 100644 >> index 000000000000..0792a2a98fc9 >> --- /dev/null >> +++ b/drivers/soc/qcom/cmd-db.c >> @@ -0,0 +1,319 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +/* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. */ >> + >> +#include <linux/kernel.h> >> +#include <linux/of.h> >> +#include <linux/of_address.h> >> +#include <linux/of_platform.h> >> +#include <linux/of_reserved_mem.h> >> +#include <linux/platform_device.h> >> +#include <linux/types.h> >> + >> +#include <soc/qcom/cmd-db.h> >> + >> +#define NUM_PRIORITY 2 >> +#define MAX_SLV_ID 8 >> +#define CMD_DB_MAGIC 0x0C0330DBUL > >Make this an array so it's endian safe. > >> +#define SLAVE_ID_MASK 0x7 >> +#define SLAVE_ID_SHIFT 16 >> + >> +#define ENTRY_HEADER(hdr) ((void *)cmd_db_header + \ >> + sizeof(*cmd_db_header) + \ >> + hdr->header_offset) >> + >> +#define RSC_OFFSET(hdr, ent) ((void *)cmd_db_header + \ >> + sizeof(*cmd_db_header) + \ >> + hdr.data_offset + ent.offset) >> + >> +/** >> + * entry_header: header for each entry in cmddb > >struct entry_header - header for each... > Ok >> + * >> + * @id: resource's identifier >> + * @priority: unused >> + * @addr: the address of the resource >> + * @len: length of the data >> + * @offset: offset at which data starts > >offset from this entry header at which data starts? Or offset from >where? > Offset from @data_offset of the rsc_header. >> + */ >> +struct entry_header { >> + u64 id; >> + u32 priority[NUM_PRIORITY]; >> + u32 addr; >> + u16 len; >> + u16 offset; >> +}; >> + >> +/** >> + * rsc_hdr: resource header information > >ditto. > Will do. >> + * >> + * @slv_id: id for the resource >> + * @header_offset: Entry header offset from data >> + * @data_offset: Entry offset for data location > >Same question: offset from where? > Ok >> + * @cnt: number of entries for HW type >> + * @version: MSB is major, LSB is minor > >@reserved: reserved for future use > Ok. >> + */ >> +struct rsc_hdr { >> + u16 slv_id; >> + u16 header_offset; >> + u16 data_offset; >> + u16 cnt; >> + u16 version; >> + u16 reserved[3]; >> +}; >> + >> +/** >> + * cmd_db_header: The DB header information >> + * >> + * @version: The cmd db version >> + * @magic_number: constant expected in the database >> + * @header: array of resources >> + * @check_sum: check sum for the header. Unused. >> + * @reserved: reserved memory >> + * @data: driver specific data >> + */ >> +struct cmd_db_header { >> + u32 version; >> + u32 magic_num; >> + struct rsc_hdr header[MAX_SLV_ID]; >> + u32 check_sum; > >Drop underscore? 'checksum' is usually one word. > Sure. >> + u32 reserved; >> + u8 data[]; >> +}; >> + >> +/** >> + * DOC: Description of the Command DB database. >> + * >> + * At the start of the command DB memory is the cmd_db_header structure. >> + * The cmd_db_header holds the version, checksum, magic key as well as an >> + * array for header for each slave (depicted by the rsc_header). Each h/w >> + * based accelerator is a 'slave' (shared resource) and has slave id indicating >> + * the type of accelerator. The rsc_header is the header for such individual >> + * slaves of a given type. The entries for each of these slaves begin at the >> + * rsc_hdr.header_offset. In addition each slave could have auxiliary data >> + * that may be needed by the driver. The data for the slave starts at the >> + * entry_header.offset to the location pointed to by the rsc_hdr.data_offset. >> + * >> + * Drivers have a stringified key to a slave/resource. They can query the slave >> + * information and get the slave id and the auxiliary data and the length of the >> + * data. Using this information, they can format the request to be sent to the >> + * h/w accelerator and request a resource state. >> + */ >> + >> +static struct cmd_db_header *cmd_db_header; >> + >> +/** >> + * cmd_db_ready - Indicates if command DB is available >> + * >> + * Return: 0 on success, errno otherwise >> + */ >> +int cmd_db_ready(void) >> +{ >> + if (cmd_db_header == NULL) >> + return -EPROBE_DEFER; >> + else if (cmd_db_header->magic_num != CMD_DB_MAGIC) >> + return -EINVAL; >> + else >> + return 0; > >Drop else and just return 0. > Ok. >> +} >> +EXPORT_SYMBOL(cmd_db_ready); >> + >> +static u64 cmd_db_get_u64_id(const char *id) >> +{ >> + u64 rsc_id = 0; >> + u8 *ch = (u8 *)&rsc_id; >> + int i; >> + >> + for (i = 0; i < sizeof(rsc_id) && id[i]; i++) >> + ch[i] = id[i]; > >This could be a strncpy now? Didn't I already ask this? I'll have to >look back at the other emails it seems. Actually, it looks like a cast >of a string to an integer, Yes, you did ask. The cast helps do an integer comparison as opposed to string comparision on the database. >which is then reversed to look up the same >string. Not sure what the use is for this. > Where do you see that? >> + >> + return rsc_id; >> +} >> + >> +static int cmd_db_get_header(u64 query, struct entry_header *eh, >> + struct rsc_hdr *rh) >> +{ >> + struct rsc_hdr *rsc_hdr; >> + struct entry_header *ent; >> + int ret, i, j; >> + >> + ret = cmd_db_ready(); >> + if (ret) >> + return ret; >> + >> + if (!eh || !rh) >> + return -EINVAL; >> + >> + for (i = 0; i < MAX_SLV_ID; i++) { >> + rsc_hdr = &cmd_db_header->header[i]; >> + if (!rsc_hdr->slv_id) >> + break; >> + >> + ent = ENTRY_HEADER(rsc_hdr); >> + for (j = 0; j < rsc_hdr->cnt; j++, ent++) { >> + if (ent->id == query) >> + break; >> + } >> + >> + if (j < rsc_hdr->cnt) { >> + memcpy(eh, ent, sizeof(*ent)); >> + memcpy(rh, rsc_hdr, sizeof(*rh)); > >I suppose it's OK to punt on the endian issues for now if it's too hard. >Eventually we'll want to handle it though and it shouldn't make the code >any worse when endianness is the same. Can it be done now? > Why is the change in endian needed? We can always add that in later if we decide to change the default endian. I would prefer that we punt it for now. >> + return 0; >> + } >> + } >> + >> + return -ENODEV; >> +} >> + >> +static int cmd_db_get_header_by_rsc_id(const char *id, >> + struct entry_header *ent_hdr, >> + struct rsc_hdr *rsc_hdr) >> +{ >> + u64 rsc_id = cmd_db_get_u64_id(id); >> + >> + return cmd_db_get_header(rsc_id, ent_hdr, rsc_hdr); >> +} >> + >> +/** >> + * cmd_db_read_addr() - Query command db for resource id address. >> + * >> + * @id: resource id to query for address >> + * >> + * This is used to retrieve resource address based on resource >> + * id. >> + * Return: resource address on success, 0 on error > >Weird spaces here. Mix of tabs and spaces perhaps? > Hmm. Not sure, didn't see checkpatch complain. Will check. >> + */ >> +u32 cmd_db_read_addr(const char *id) >> +{ >> + int ret; >> + struct entry_header ent; >> + struct rsc_hdr rsc_hdr; >> + >> + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); >> + >> + return ret < 0 ? 0 : ent.addr; >> +} >> +EXPORT_SYMBOL(cmd_db_read_addr); >> + >> +/** >> + * cmd_db_read_aux_data() - Query command db for aux data. >> + * >> + * @id : Resource to retrieve AUX Data on. >> + * @data : Data buffer to copy returned aux data to. Returns size on NULL >> + * @len : Caller provides size of data buffer passed in. > >Attach the ':' to the variable please. > Ok >> + * >> + * Return: size of data on success, errno on error > >success, -EINVAL on error > Ok >> + */ >> +int cmd_db_read_aux_data(const char *id, u8 *data, int len) >> +{ >> + int ret; >> + struct entry_header ent; >> + struct rsc_hdr rsc_hdr; >> + >> + if (!data) >> + return -EINVAL; >> + >> + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); >> + if (ret) >> + return ret; >> + >> + if (len < ent.len) >> + return -EINVAL; >> + >> + len = min_t(u16, ent.len, len); >> + memcpy(data, RSC_OFFSET(rsc_hdr, ent), len); >> + >> + return len; >> +} >> +EXPORT_SYMBOL(cmd_db_read_aux_data); >> + >> +/** >> + * cmd_db_read_aux_data_len - Get the length of the auxllary data stored in DB. >> + * >> + * @id: Resource to retrieve AUX Data. >> + * >> + * Return: size on success, 0 on error >> + */ >> +size_t cmd_db_read_aux_data_len(const char *id) >> +{ >> + int ret; >> + struct entry_header ent; >> + struct rsc_hdr rsc_hdr; >> + >> + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); > >A bunch of code is calling this function. Why not change the user >interface to use an opaque 'resource' cookie that we can 'get' or 'find' >and then use that cookie in the rest of the API to pull out the data >that's desired? > Fair point. Let me find out. I suspect this was done to keep the API similar to other non-Linux interfaces. I am not sure why they all didn't use a handle instead of char *. >> + >> + return ret < 0 ? 0 : ent.len; >> +} >> +EXPORT_SYMBOL(cmd_db_read_aux_data_len); >> + >> +/** >> + * cmd_db_read_slave_id - Get the slave ID for a given resource address >> + * >> + * @id: Resource id to query the DB for version >> + * >> + * Return: cmd_db_hw_type enum on success, CMD_DB_HW_INVALID on error >> + */ >> +enum cmd_db_hw_type cmd_db_read_slave_id(const char *id) >> +{ >> + int ret; >> + struct entry_header ent; >> + struct rsc_hdr rsc_hdr; >> + >> + ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); >> + >> + return ret < 0 ? CMD_DB_HW_INVALID : >> + (ent.addr >> SLAVE_ID_SHIFT) & SLAVE_ID_MASK; >> +} >> +EXPORT_SYMBOL(cmd_db_read_slave_id); >> + >> +static int cmd_db_dev_probe(struct platform_device *pdev) >> +{ >> + struct reserved_mem *rmem; >> + void *dict, *start_addr; >> + int ret = 0; >> + >> + rmem = of_reserved_mem_lookup(pdev->dev.of_node); >> + if (!rmem) { >> + dev_err(&pdev->dev, "failed to acquire memory region\n"); >> + return -EINVAL; >> + } >> + >> + dict = devm_memremap(&pdev->dev, rmem->base, rmem->size, MEMREMAP_WB); >> + if (IS_ERR(dict)) >> + return -ENOMEM; >> + >> + start_addr = memremap(readl_relaxed(dict), readl_relaxed(dict + 0x4), >> + MEMREMAP_WB); >> + if (IS_ERR_OR_NULL(start_addr)) { > >Should just be !start_addr? I don't see where memremap() returns an >error pointer. > Sure. >> + ret = PTR_ERR(start_addr); >> + goto done; >> + } >> + >> + cmd_db_header = start_addr; >> + if (cmd_db_header->magic_num != CMD_DB_MAGIC) { > >memcmp? > Why? It could be a simple comparison. >> + ret = -EINVAL; >> + dev_err(&pdev->dev, "Invalid Command DB Magic\n"); >> + goto done; >> + } >> + >> +done: >> + devm_memunmap(&pdev->dev, dict); > >I'm lost why we use devm_*() for this mapping. > Must have picked it up from an example. Curious, why not though? >> + return ret; >> +} >> + >> +static const struct of_device_id cmd_db_match_table[] = { >> + { .compatible = "qcom,cmd-db" }, >> + { }, >> +}; >> + >> +static struct platform_driver cmd_db_dev_driver = { >> + .probe = cmd_db_dev_probe, >> + .driver = { >> + .name = "cmd-db", >> + .of_match_table = cmd_db_match_table, > >Add suppress_bind_attrs here to make sure we can't remove this device >later? That also allows us to ignore unmapping the start_addr pointer >in any sort of 'remove' function. > Ok.. Thanks Stephen. -- Lina ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/2] drivers: qcom: add command DB driver 2018-03-06 16:21 ` Lina Iyer @ 2018-03-06 16:56 ` Lina Iyer 2018-03-06 22:08 ` Stephen Boyd 2018-03-06 22:08 ` Stephen Boyd 1 sibling, 1 reply; 16+ messages in thread From: Lina Iyer @ 2018-03-06 16:56 UTC (permalink / raw) To: Stephen Boyd Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, bjorn.andersson, linux-kernel, Mahesh Sivasubramanian On Tue, Mar 06 2018 at 09:21 -0700, Lina Iyer wrote: >On Mon, Mar 05 2018 at 11:42 -0700, Stephen Boyd wrote: >>Quoting Lina Iyer (2018-02-26 09:58:01) >>>+size_t cmd_db_read_aux_data_len(const char *id) >>>+{ >>>+ int ret; >>>+ struct entry_header ent; >>>+ struct rsc_hdr rsc_hdr; >>>+ >>>+ ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); >> >>A bunch of code is calling this function. Why not change the user >>interface to use an opaque 'resource' cookie that we can 'get' or 'find' >>and then use that cookie in the rest of the API to pull out the data >>that's desired? >> >Fair point. Let me find out. I suspect this was done to keep the API >similar to other non-Linux interfaces. I am not sure why they all didn't >use a handle instead of char *. > I was reminded that the APIs are generally used once for each resource and are used for multiple resources and usually only at init. The handle method doesn't buy much in benefits. -- Lina ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/2] drivers: qcom: add command DB driver 2018-03-06 16:56 ` Lina Iyer @ 2018-03-06 22:08 ` Stephen Boyd 0 siblings, 0 replies; 16+ messages in thread From: Stephen Boyd @ 2018-03-06 22:08 UTC (permalink / raw) To: Lina Iyer Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, bjorn.andersson, linux-kernel, Mahesh Sivasubramanian Quoting Lina Iyer (2018-03-06 08:56:19) > On Tue, Mar 06 2018 at 09:21 -0700, Lina Iyer wrote: > >On Mon, Mar 05 2018 at 11:42 -0700, Stephen Boyd wrote: > >>Quoting Lina Iyer (2018-02-26 09:58:01) > >>>+size_t cmd_db_read_aux_data_len(const char *id) > >>>+{ > >>>+ int ret; > >>>+ struct entry_header ent; > >>>+ struct rsc_hdr rsc_hdr; > >>>+ > >>>+ ret = cmd_db_get_header_by_rsc_id(id, &ent, &rsc_hdr); > >> > >>A bunch of code is calling this function. Why not change the user > >>interface to use an opaque 'resource' cookie that we can 'get' or 'find' > >>and then use that cookie in the rest of the API to pull out the data > >>that's desired? > >> > >Fair point. Let me find out. I suspect this was done to keep the API > >similar to other non-Linux interfaces. I am not sure why they all didn't > >use a handle instead of char *. > > > I was reminded that the APIs are generally used once for each resource > and are used for multiple resources and usually only at init. The handle > method doesn't buy much in benefits. > Ok. Let's take the wait and see approach then. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/2] drivers: qcom: add command DB driver 2018-03-06 16:21 ` Lina Iyer 2018-03-06 16:56 ` Lina Iyer @ 2018-03-06 22:08 ` Stephen Boyd 1 sibling, 0 replies; 16+ messages in thread From: Stephen Boyd @ 2018-03-06 22:08 UTC (permalink / raw) To: Lina Iyer Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, bjorn.andersson, linux-kernel, Mahesh Sivasubramanian Quoting Lina Iyer (2018-03-06 08:21:40) > On Mon, Mar 05 2018 at 11:42 -0700, Stephen Boyd wrote: > >Quoting Lina Iyer (2018-02-26 09:58:01) > > >> +} > >> +EXPORT_SYMBOL(cmd_db_ready); > >> + > >> +static u64 cmd_db_get_u64_id(const char *id) > >> +{ > >> + u64 rsc_id = 0; > >> + u8 *ch = (u8 *)&rsc_id; > >> + int i; > >> + > >> + for (i = 0; i < sizeof(rsc_id) && id[i]; i++) > >> + ch[i] = id[i]; > > > >This could be a strncpy now? Didn't I already ask this? I'll have to > >look back at the other emails it seems. Actually, it looks like a cast > >of a string to an integer, > Yes, you did ask. The cast helps do an integer comparison as opposed to > string comparision on the database. > > >which is then reversed to look up the same > >string. Not sure what the use is for this. > > > Where do you see that? Hmm no idea. I must have seen something wrong. Ignore this one. > > >> + > >> + return rsc_id; > >> +} > >> + > >> +static int cmd_db_get_header(u64 query, struct entry_header *eh, > >> + struct rsc_hdr *rh) > >> +{ > >> + struct rsc_hdr *rsc_hdr; > >> + struct entry_header *ent; > >> + int ret, i, j; > >> + > >> + ret = cmd_db_ready(); > >> + if (ret) > >> + return ret; > >> + > >> + if (!eh || !rh) > >> + return -EINVAL; > >> + > >> + for (i = 0; i < MAX_SLV_ID; i++) { > >> + rsc_hdr = &cmd_db_header->header[i]; > >> + if (!rsc_hdr->slv_id) > >> + break; > >> + > >> + ent = ENTRY_HEADER(rsc_hdr); > >> + for (j = 0; j < rsc_hdr->cnt; j++, ent++) { > >> + if (ent->id == query) > >> + break; > >> + } > >> + > >> + if (j < rsc_hdr->cnt) { > >> + memcpy(eh, ent, sizeof(*ent)); > >> + memcpy(rh, rsc_hdr, sizeof(*rh)); > > > >I suppose it's OK to punt on the endian issues for now if it's too hard. > >Eventually we'll want to handle it though and it shouldn't make the code > >any worse when endianness is the same. Can it be done now? > > > Why is the change in endian needed? We can always add that in later if > we decide to change the default endian. I would prefer that we punt it > for now. Ok! > > >> + ret = PTR_ERR(start_addr); > >> + goto done; > >> + } > >> + > >> + cmd_db_header = start_addr; > >> + if (cmd_db_header->magic_num != CMD_DB_MAGIC) { > > > >memcmp? > > > Why? It could be a simple comparison. Endian stuff again > > >> + ret = -EINVAL; > >> + dev_err(&pdev->dev, "Invalid Command DB Magic\n"); > >> + goto done; > >> + } > >> + > >> +done: > >> + devm_memunmap(&pdev->dev, dict); > > > >I'm lost why we use devm_*() for this mapping. > > > Must have picked it up from an example. Curious, why not though? devm is usually used for long lived things that need to be released on driver removal. At least that's the way I view it. For short lived things that are created and then freed in the same scope I usually avoid devm. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs 2018-02-26 17:58 [PATCH v4 0/2] drivers/qcom: add Command DB support Lina Iyer 2018-02-26 17:58 ` [PATCH v4 1/2] drivers: qcom: add command DB driver Lina Iyer @ 2018-02-26 17:58 ` Lina Iyer 2018-03-05 21:10 ` Rob Herring ` (2 more replies) 1 sibling, 3 replies; 16+ messages in thread From: Lina Iyer @ 2018-02-26 17:58 UTC (permalink / raw) To: andy.gross, david.brown, linux-arm-msm, linux-soc Cc: rnayak, bjorn.andersson, linux-kernel, Lina Iyer, devicetree, Mahesh Sivasubramanian From: Mahesh Sivasubramanian <msivasub@codeaurora.org> Command DB provides information on shared resources like clocks, regulators etc., probed at boot by the remote subsytem and made available in shared memory. Cc: devicetree@vger.kernel.org Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> Signed-off-by: Lina Iyer <ilina@codeaurora.org> --- Changes in v4: - Fix unwanted capitalization - Add reg property --- .../devicetree/bindings/arm/msm/cmd-db.txt | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/msm/cmd-db.txt diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt new file mode 100644 index 000000000000..5737ed2ac6e8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt @@ -0,0 +1,38 @@ +Command DB +--------- + +Command DB is a database that provides a mapping between resource key and the +resource address for a system resource managed by a remote processor. The data +is stored in a shared memory region and is loaded by the remote processor. + +Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for +controlling shared resources. Depending on the board configuration the shared +resource properties may change. These properties are dynamically probed by the +remote processor and made available in the shared memory. + +The bindings for Command DB is specified in the reserved-memory section in +devicetree. The devicetree representation of the command DB driver should be: + +Properties: +- compatible: + Usage: required + Value type: <string> + Definition: Should be "qcom,cmd-db" + +- reg: + Usage: required + Value type: <prop encoded array> + Definition: The register address that points to the location of the + Command DB in memory. Additionally, specify the address + and size of the actual lacation in memory. + +Example: + + reserved-memory { + [...] + qcom,cmd-db@c3f000c { + reg = <0x0 0xc3f000c 0x0 0x8>, + <0x0 0x85fe0000 0x0 0x20000>; + compatible = "qcom,cmd-db"; + }; + }; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs 2018-02-26 17:58 ` [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs Lina Iyer @ 2018-03-05 21:10 ` Rob Herring 2018-03-05 23:14 ` Bjorn Andersson 2018-03-06 0:21 ` Stephen Boyd 2 siblings, 0 replies; 16+ messages in thread From: Rob Herring @ 2018-03-05 21:10 UTC (permalink / raw) To: Lina Iyer Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, bjorn.andersson, linux-kernel, devicetree, Mahesh Sivasubramanian On Mon, Feb 26, 2018 at 10:58:02AM -0700, Lina Iyer wrote: > From: Mahesh Sivasubramanian <msivasub@codeaurora.org> > > Command DB provides information on shared resources like clocks, > regulators etc., probed at boot by the remote subsytem and made > available in shared memory. > > Cc: devicetree@vger.kernel.org > Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> > Signed-off-by: Lina Iyer <ilina@codeaurora.org> > --- > > Changes in v4: > - Fix unwanted capitalization > - Add reg property > --- > .../devicetree/bindings/arm/msm/cmd-db.txt | 38 ++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/msm/cmd-db.txt Reviewed-by: Rob Herring <robh@kernel.org> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs 2018-02-26 17:58 ` [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs Lina Iyer 2018-03-05 21:10 ` Rob Herring @ 2018-03-05 23:14 ` Bjorn Andersson 2018-03-06 15:57 ` Lina Iyer 2018-03-06 0:21 ` Stephen Boyd 2 siblings, 1 reply; 16+ messages in thread From: Bjorn Andersson @ 2018-03-05 23:14 UTC (permalink / raw) To: Lina Iyer Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, linux-kernel, devicetree, Mahesh Sivasubramanian On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > From: Mahesh Sivasubramanian <msivasub@codeaurora.org> > > Command DB provides information on shared resources like clocks, > regulators etc., probed at boot by the remote subsytem and made > available in shared memory. > > Cc: devicetree@vger.kernel.org > Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> > Signed-off-by: Lina Iyer <ilina@codeaurora.org> > --- > > Changes in v4: > - Fix unwanted capitalization > - Add reg property > --- > .../devicetree/bindings/arm/msm/cmd-db.txt | 38 ++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/msm/cmd-db.txt > > diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt [..] > + reserved-memory { > + [...] > + qcom,cmd-db@c3f000c { > + reg = <0x0 0xc3f000c 0x0 0x8>, > + <0x0 0x85fe0000 0x0 0x20000>; I'm still concerned about the use of the redirection mapping here, the relocation at 0xc3f000c is used a convenience thing so that the command db can be relocated, but because of how Linux will consume any non-reserved memory the dts would still need to be manually updated. As such I think you should just describe only the 0x85fe0000 + 0x20000 region here and to support the dynamic aspect of this from a system point of view you can have the boot loader read the information at 0xc3f000c and adjust the reserved memory. (Or just keep the step of manually update the dts without caring about the indirection) Regards, Bjorn ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs 2018-03-05 23:14 ` Bjorn Andersson @ 2018-03-06 15:57 ` Lina Iyer 2018-03-07 19:02 ` Bjorn Andersson 0 siblings, 1 reply; 16+ messages in thread From: Lina Iyer @ 2018-03-06 15:57 UTC (permalink / raw) To: Bjorn Andersson Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, linux-kernel, devicetree, Mahesh Sivasubramanian On Mon, Mar 05 2018 at 16:15 -0700, Bjorn Andersson wrote: >On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > >> From: Mahesh Sivasubramanian <msivasub@codeaurora.org> >> >> Command DB provides information on shared resources like clocks, >> regulators etc., probed at boot by the remote subsytem and made >> available in shared memory. >> >> Cc: devicetree@vger.kernel.org >> Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> >> Signed-off-by: Lina Iyer <ilina@codeaurora.org> >> --- >> >> Changes in v4: >> - Fix unwanted capitalization >> - Add reg property >> --- >> .../devicetree/bindings/arm/msm/cmd-db.txt | 38 ++++++++++++++++++++++ >> 1 file changed, 38 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/arm/msm/cmd-db.txt >> >> diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt >[..] >> + reserved-memory { >> + [...] >> + qcom,cmd-db@c3f000c { >> + reg = <0x0 0xc3f000c 0x0 0x8>, >> + <0x0 0x85fe0000 0x0 0x20000>; > >I'm still concerned about the use of the redirection mapping here, >the relocation at 0xc3f000c is used a convenience thing so that the >command db can be relocated, but because of how Linux will consume any >non-reserved memory the dts would still need to be manually updated. > This location is fixed and it is not expected to change between different boards. OEMs may change the actual address of the command db location, but would not change the dictionary location. >As such I think you should just describe only the 0x85fe0000 + 0x20000 >region here and to support the dynamic aspect of this from a system >point of view you can have the boot loader read the information at >0xc3f000c and adjust the reserved memory. (Or just keep the step of >manually update the dts without caring about the indirection) > It would be incorrect and very board specific to just use the 0x85fe000 as the address. It is not how the SoC defines the location. Upon request earlier, this memory location was added in DT and the location is typical reference platform usage only. Thanks, Lina ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs 2018-03-06 15:57 ` Lina Iyer @ 2018-03-07 19:02 ` Bjorn Andersson 2018-03-16 18:26 ` Stephen Boyd 0 siblings, 1 reply; 16+ messages in thread From: Bjorn Andersson @ 2018-03-07 19:02 UTC (permalink / raw) To: Lina Iyer Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, linux-kernel, devicetree, Mahesh Sivasubramanian On Tue 06 Mar 07:57 PST 2018, Lina Iyer wrote: > On Mon, Mar 05 2018 at 16:15 -0700, Bjorn Andersson wrote: > > On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > > > > > From: Mahesh Sivasubramanian <msivasub@codeaurora.org> > > > > > > Command DB provides information on shared resources like clocks, > > > regulators etc., probed at boot by the remote subsytem and made > > > available in shared memory. > > > > > > Cc: devicetree@vger.kernel.org > > > Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> > > > Signed-off-by: Lina Iyer <ilina@codeaurora.org> > > > --- > > > > > > Changes in v4: > > > - Fix unwanted capitalization > > > - Add reg property > > > --- > > > .../devicetree/bindings/arm/msm/cmd-db.txt | 38 ++++++++++++++++++++++ > > > 1 file changed, 38 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/arm/msm/cmd-db.txt > > > > > > diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt > > [..] > > > + reserved-memory { > > > + [...] > > > + qcom,cmd-db@c3f000c { > > > + reg = <0x0 0xc3f000c 0x0 0x8>, > > > + <0x0 0x85fe0000 0x0 0x20000>; > > > > I'm still concerned about the use of the redirection mapping here, > > the relocation at 0xc3f000c is used a convenience thing so that the > > command db can be relocated, but because of how Linux will consume any > > non-reserved memory the dts would still need to be manually updated. > > > This location is fixed and it is not expected to change between > different boards. OEMs may change the actual address of the command db > location, but would not change the dictionary location. > Right, dictionary location is fixed. So to pick another range for command db one would update the numbers that goes into the dictionary and expect all software in the system to use this new range. > > As such I think you should just describe only the 0x85fe0000 + 0x20000 > > region here and to support the dynamic aspect of this from a system > > point of view you can have the boot loader read the information at > > 0xc3f000c and adjust the reserved memory. (Or just keep the step of > > manually update the dts without caring about the indirection) > > > It would be incorrect and very board specific to just use the 0x85fe000 > as the address. It is not how the SoC defines the location. Upon request > earlier, this memory location was added in DT and the location is > typical reference platform usage only. > The problem is that as the db resides in a chunk of memory in the middle of what Linux considers System RAM the DTS must specify this region as reserved. Which means that as you, like described above, update the dictionary something (in your scheme a person) has to update the reserved-memory region as well. That's why I'm proposing that the appropriate implementation for this is to have the boot loader to the dictionary part of this and Linux only care about the actual reserved-memory region. This way you would still implement the dictionary lookup on a system level, but the Linux part no longer depend on a human updating the DTS to match the values of the dictionary. But if we stick with the approach of describing both these and hoping that the values in the first region matches the second (or should we add a sanity check in probe?). The memory reserve defined as 0xc3f000c + 8 looks strange, is this system ram as well and what other things resides in that same page? Regards, Bjorn ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs 2018-03-07 19:02 ` Bjorn Andersson @ 2018-03-16 18:26 ` Stephen Boyd 2018-03-16 19:55 ` Bjorn Andersson 0 siblings, 1 reply; 16+ messages in thread From: Stephen Boyd @ 2018-03-16 18:26 UTC (permalink / raw) To: Bjorn Andersson, Lina Iyer Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, linux-kernel, devicetree, Mahesh Sivasubramanian Quoting Bjorn Andersson (2018-03-07 11:02:49) > On Tue 06 Mar 07:57 PST 2018, Lina Iyer wrote: > > > On Mon, Mar 05 2018 at 16:15 -0700, Bjorn Andersson wrote: > > > On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > > > > As such I think you should just describe only the 0x85fe0000 + 0x20000 > > > region here and to support the dynamic aspect of this from a system > > > point of view you can have the boot loader read the information at > > > 0xc3f000c and adjust the reserved memory. (Or just keep the step of > > > manually update the dts without caring about the indirection) > > > > > It would be incorrect and very board specific to just use the 0x85fe000 > > as the address. It is not how the SoC defines the location. Upon request > > earlier, this memory location was added in DT and the location is > > typical reference platform usage only. > > > > The problem is that as the db resides in a chunk of memory in the middle > of what Linux considers System RAM the DTS must specify this region as > reserved. Which means that as you, like described above, update the > dictionary something (in your scheme a person) has to update the > reserved-memory region as well. > > That's why I'm proposing that the appropriate implementation for this > is to have the boot loader to the dictionary part of this and Linux only > care about the actual reserved-memory region. This way you would still > implement the dictionary lookup on a system level, but the Linux > part no longer depend on a human updating the DTS to match the values of > the dictionary. Agreed. I thought SMEM had a similar design of a cookie in IMEM to indicate location and size because coordinating changes across all the various software images is a hard problem. But coordinating between linux and the linux bootloader shouldn't be as hard. > > > But if we stick with the approach of describing both these and hoping > that the values in the first region matches the second (or should we add > a sanity check in probe?). The memory reserve defined as 0xc3f000c + 8 > looks strange, is this system ram as well and what other things resides > in that same page? > Doesn't look like it could be RAM, the address is not very close to the other one so I would guess it's something like IMEM. And there are two 32-bit numbers to describe address and size? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs 2018-03-16 18:26 ` Stephen Boyd @ 2018-03-16 19:55 ` Bjorn Andersson 0 siblings, 0 replies; 16+ messages in thread From: Bjorn Andersson @ 2018-03-16 19:55 UTC (permalink / raw) To: Stephen Boyd Cc: Lina Iyer, andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, linux-kernel, devicetree, Mahesh Sivasubramanian On Fri 16 Mar 11:26 PDT 2018, Stephen Boyd wrote: > Quoting Bjorn Andersson (2018-03-07 11:02:49) > > On Tue 06 Mar 07:57 PST 2018, Lina Iyer wrote: > > > > > On Mon, Mar 05 2018 at 16:15 -0700, Bjorn Andersson wrote: > > > > On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > > > > > > As such I think you should just describe only the 0x85fe0000 + 0x20000 > > > > region here and to support the dynamic aspect of this from a system > > > > point of view you can have the boot loader read the information at > > > > 0xc3f000c and adjust the reserved memory. (Or just keep the step of > > > > manually update the dts without caring about the indirection) > > > > > > > It would be incorrect and very board specific to just use the 0x85fe000 > > > as the address. It is not how the SoC defines the location. Upon request > > > earlier, this memory location was added in DT and the location is > > > typical reference platform usage only. > > > > > > > The problem is that as the db resides in a chunk of memory in the middle > > of what Linux considers System RAM the DTS must specify this region as > > reserved. Which means that as you, like described above, update the > > dictionary something (in your scheme a person) has to update the > > reserved-memory region as well. > > > > That's why I'm proposing that the appropriate implementation for this > > is to have the boot loader to the dictionary part of this and Linux only > > care about the actual reserved-memory region. This way you would still > > implement the dictionary lookup on a system level, but the Linux > > part no longer depend on a human updating the DTS to match the values of > > the dictionary. > > Agreed. I thought SMEM had a similar design of a cookie in IMEM to > indicate location and size because coordinating changes across all the > various software images is a hard problem. But coordinating between > linux and the linux bootloader shouldn't be as hard. > Correct, SMEM has exactly the same mechanism. I get that the coordinating of these addresses between all involved images can be a tricky thing, but the only way to make this automatic on the application CPU is to split this between boot and Linux; as any all-Linux solution requires a human to update the reserved-memory node to match the values in the indirection. So for SMEM we agreed that we implement this as "someone needs to tell Linux where SMEM is" and that can be a human or the boot loader. Regards, Bjorn ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs 2018-02-26 17:58 ` [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs Lina Iyer 2018-03-05 21:10 ` Rob Herring 2018-03-05 23:14 ` Bjorn Andersson @ 2018-03-06 0:21 ` Stephen Boyd 2018-03-06 15:57 ` Lina Iyer 2 siblings, 1 reply; 16+ messages in thread From: Stephen Boyd @ 2018-03-06 0:21 UTC (permalink / raw) To: Lina Iyer, andy.gross, david.brown, linux-arm-msm, linux-soc Cc: rnayak, bjorn.andersson, linux-kernel, Lina Iyer, devicetree, Mahesh Sivasubramanian Quoting Lina Iyer (2018-02-26 09:58:02) > diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt > new file mode 100644 > index 000000000000..5737ed2ac6e8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt > @@ -0,0 +1,38 @@ > +Command DB > +--------- > + > +Command DB is a database that provides a mapping between resource key and the s/between/between the/ > +resource address for a system resource managed by a remote processor. The data > +is stored in a shared memory region and is loaded by the remote processor. > + > +Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for s/SoC's/SoCs/ > +controlling shared resources. Depending on the board configuration the shared > +resource properties may change. These properties are dynamically probed by the > +remote processor and made available in the shared memory. > + > +The bindings for Command DB is specified in the reserved-memory section in s/bindings/node/ maybe? > +devicetree. The devicetree representation of the command DB driver should be: Maybe drop this last sentence entirely. > + > +Properties: > +- compatible: > + Usage: required > + Value type: <string> > + Definition: Should be "qcom,cmd-db" > + > +- reg: > + Usage: required > + Value type: <prop encoded array> > + Definition: The register address that points to the location of the > + Command DB in memory. Additionally, specify the address > + and size of the actual lacation in memory. s/lacation/location/ > + > +Example: > + > + reserved-memory { > + [...] > + qcom,cmd-db@c3f000c { > + reg = <0x0 0xc3f000c 0x0 0x8>, > + <0x0 0x85fe0000 0x0 0x20000>; > + compatible = "qcom,cmd-db"; > + }; > + }; ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs 2018-03-06 0:21 ` Stephen Boyd @ 2018-03-06 15:57 ` Lina Iyer 0 siblings, 0 replies; 16+ messages in thread From: Lina Iyer @ 2018-03-06 15:57 UTC (permalink / raw) To: Stephen Boyd Cc: andy.gross, david.brown, linux-arm-msm, linux-soc, rnayak, bjorn.andersson, linux-kernel, devicetree, Mahesh Sivasubramanian On Mon, Mar 05 2018 at 17:21 -0700, Stephen Boyd wrote: >Quoting Lina Iyer (2018-02-26 09:58:02) >> diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt >> new file mode 100644 >> index 000000000000..5737ed2ac6e8 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt >> @@ -0,0 +1,38 @@ >> +Command DB >> +--------- >> + >> +Command DB is a database that provides a mapping between resource key and the > >s/between/between the/ > >> +resource address for a system resource managed by a remote processor. The data >> +is stored in a shared memory region and is loaded by the remote processor. >> + >> +Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for > >s/SoC's/SoCs/ > >> +controlling shared resources. Depending on the board configuration the shared >> +resource properties may change. These properties are dynamically probed by the >> +remote processor and made available in the shared memory. >> + >> +The bindings for Command DB is specified in the reserved-memory section in > >s/bindings/node/ > >maybe? > >> +devicetree. The devicetree representation of the command DB driver should be: > >Maybe drop this last sentence entirely. > >> + >> +Properties: >> +- compatible: >> + Usage: required >> + Value type: <string> >> + Definition: Should be "qcom,cmd-db" >> + >> +- reg: >> + Usage: required >> + Value type: <prop encoded array> >> + Definition: The register address that points to the location of the >> + Command DB in memory. Additionally, specify the address >> + and size of the actual lacation in memory. > >s/lacation/location/ > Will take care of these in the next spin. >> + >> +Example: >> + >> + reserved-memory { >> + [...] >> + qcom,cmd-db@c3f000c { >> + reg = <0x0 0xc3f000c 0x0 0x8>, >> + <0x0 0x85fe0000 0x0 0x20000>; >> + compatible = "qcom,cmd-db"; >> + }; >> + }; ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2018-03-16 20:01 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-26 17:58 [PATCH v4 0/2] drivers/qcom: add Command DB support Lina Iyer 2018-02-26 17:58 ` [PATCH v4 1/2] drivers: qcom: add command DB driver Lina Iyer 2018-03-05 18:42 ` Stephen Boyd 2018-03-06 16:21 ` Lina Iyer 2018-03-06 16:56 ` Lina Iyer 2018-03-06 22:08 ` Stephen Boyd 2018-03-06 22:08 ` Stephen Boyd 2018-02-26 17:58 ` [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs Lina Iyer 2018-03-05 21:10 ` Rob Herring 2018-03-05 23:14 ` Bjorn Andersson 2018-03-06 15:57 ` Lina Iyer 2018-03-07 19:02 ` Bjorn Andersson 2018-03-16 18:26 ` Stephen Boyd 2018-03-16 19:55 ` Bjorn Andersson 2018-03-06 0:21 ` Stephen Boyd 2018-03-06 15:57 ` Lina Iyer
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).