Merge tag 'rproc-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux

Pull remoteproc updates from Bjorn Andersson: - Add i.MX94 support to the i.MX remoteproc driver, covering the Cortex-M7 and Cortex-M33 Sync cores. This also fixes programming of non-zero System Manager CPU/LMM reset vectors. - Move the remoteproc resource table definitions to a separate header, so they can be used by clients that do not otherwise depend on remoteproc. Switch the firmware resource handling over to the common iterator. - Update the Xilinx R5F remoteproc driver to check the remote core state before attaching, drop a binding header dependency, and add firmware-name based auto boot support. - Add Qualcomm Hawi ADSP/CDSP bindings, together with Shikra RPM bindings and CDSP, LPAICP, and MPSS PAS support. Fix a Qualcomm minidump leak, clean up PAS and WCSS reset handling, and make the user-visible Qualcomm naming consistent. - Remove a duplicate STM32_RPROC Kconfig dependency and make i.MX remoteproc instances use the device node name so multiple processors can be distinguished in sysfs. * tag 'rproc-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: remoteproc: qcom: pas: Drop start/stop completion from struct qcom_pas remoteproc: qcom: pas: Add Shikra remoteproc support dt-bindings: remoteproc: qcom,shikra-pas: Document Shikra PAS remoteprocs dt-bindings: remoteproc: Add Shikra RPM processor compatible remoteproc: qcom: Unify user-visible "Qualcomm" name remoteproc: qcom: Fix leak when custom dump_segments addition fails remoteproc: qcom_q6v5_wcss: drop redundant wcss_q6_bcr_reset dt-bindings: remoteproc: qcom,sm8550-pas: Add Hawi CDSP compatible dt-bindings: remoteproc: qcom,sm8550-pas: Add Hawi ADSP compatible remoteproc: xlnx: Enable auto boot feature dt-bindings: remoteproc: xlnx: Add firmware-name property remoteproc: xlnx: Remove binding header dependency remoteproc: imx_rproc: Use device node name as processor name remoteproc: use rsc_table_for_each_entry() in rproc_handle_resources() remoteproc: Move resource table data structure to its own header remoteproc: xlnx: Check remote core state remoteproc: imx_rproc: Add support for i.MX94 remoteproc: imx_rproc: Program non-zero SM CPU/LMM reset vector dt-bindings: remoteproc: imx-rproc: Support i.MX94 remoteproc: Dead code cleanup in Kconfig for STM32_RPROC

Linus Torvalds committed 4 months ago

Commit 9d0d4d12 parents 390d73a b5bfc7d17 files · +858 −367Browse files

Showing the changes to include (3 of 17 files). Show all

Unified · Split

3 files

include/linux/firmware/xlnx-zynqmp.h +21 −0
include/linux/remoteproc.h +1 −268
include/linux/rsc_table.h +359 −0

include/linux/firmware/xlnx-zynqmp.h+21−0

@@ -542,6 +542,18 @@ enum pm_gem_config_type { · 541 unmodified lines
542	542	GEM_CONFIG_FIXED = 2,
543	543	};
544	544
	545	+/**
	546	+ * enum pm_node_status - Device node status provided by xilpm fw
	547	+ * @PM_NODE_UNUSED: Device is not used
	548	+ * @PM_NODE_RUNNING: Device is power-on and out of reset
	549	+ * @PM_NODE_HALT: Device is power-on but in the reset state
	550	+ */
	551	+enum pm_node_status {
	552	+ PM_NODE_UNUSED = 0,
	553	+ PM_NODE_RUNNING = 1,
	554	+ PM_NODE_HALT = 12,
	555	+};
	556	+
545	557	/**
546	558	* struct zynqmp_pm_query_data - PM query data
547	559	* @qid: query ID
@@ -630,6 +642,8 @@ int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode); · 82 unmodified lines
630	642	int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode);
631	643	int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
632	644	u32 const requirements, u32 const usage);
	645	+int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
	646	+ u32 const requirements, u32 const usage);
633	647	int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
634	648	int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
635	649	u32 value);
@@ -939,6 +953,13 @@ static inline int zynqmp_pm_get_node_status(const u32 node, u32 *const status, · 303 unmodified lines
939	953	return -ENODEV;
940	954	}
941	955
	956	+static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
	957	+ u32 *const requirements,
	958	+ u32 *const usage)
	959	+{
	960	+ return -ENODEV;
	961	+}
	962	+
942	963	static inline int zynqmp_pm_set_sd_config(u32 node,
943	964	enum pm_sd_config_type config,
944	965	u32 value)

include/linux/remoteproc.h+1−268

@@ -42,274 +42,7 @@ · 41 unmodified lines
42	42	#include <linux/completion.h>
43	43	#include <linux/idr.h>
44	44	#include <linux/of.h>
45		−
46		−/**
47		− * struct resource_table - firmware resource table header
48		− * @ver: version number
49		− * @num: number of resource entries
50		− * @reserved: reserved (must be zero)
51		− * @offset: array of offsets pointing at the various resource entries
52		− *
53		− * A resource table is essentially a list of system resources required
54		− * by the remote processor. It may also include configuration entries.
55		− * If needed, the remote processor firmware should contain this table
56		− * as a dedicated ".resource_table" ELF section.
57		− *
58		− * Some resources entries are mere announcements, where the host is informed
59		− * of specific remoteproc configuration. Other entries require the host to
60		− * do something (e.g. allocate a system resource). Sometimes a negotiation
61		− * is expected, where the firmware requests a resource, and once allocated,
62		− * the host should provide back its details (e.g. address of an allocated
63		− * memory region).
64		− *
65		− * The header of the resource table, as expressed by this structure,
66		− * contains a version number (should we need to change this format in the
67		− * future), the number of available resource entries, and their offsets
68		− * in the table.
69		− *
70		− * Immediately following this header are the resource entries themselves,
71		− * each of which begins with a resource entry header (as described below).
72		− */
73		−struct resource_table {
74		− u32 ver;
75		− u32 num;
76		− u32 reserved[2];
77		− u32 offset[];
78		−} __packed;
79		−
80		−/**
81		− * struct fw_rsc_hdr - firmware resource entry header
82		− * @type: resource type
83		− * @data: resource data
84		− *
85		− * Every resource entry begins with a 'struct fw_rsc_hdr' header providing
86		− * its @type. The content of the entry itself will immediately follow
87		− * this header, and it should be parsed according to the resource type.
88		− */
89		−struct fw_rsc_hdr {
90		− u32 type;
91		− u8 data[];
92		−} __packed;
93		−
94		−/**
95		− * enum fw_resource_type - types of resource entries
96		− *
97		− * @RSC_CARVEOUT: request for allocation of a physically contiguous
98		− * memory region.
99		− * @RSC_DEVMEM: request to iommu_map a memory-based peripheral.
100		− * @RSC_TRACE: announces the availability of a trace buffer into which
101		− * the remote processor will be writing logs.
102		− * @RSC_VDEV: declare support for a virtio device, and serve as its
103		− * virtio header.
104		− * @RSC_LAST: just keep this one at the end of standard resources
105		− * @RSC_VENDOR_START: start of the vendor specific resource types range
106		− * @RSC_VENDOR_END: end of the vendor specific resource types range
107		− *
108		− * For more details regarding a specific resource type, please see its
109		− * dedicated structure below.
110		− *
111		− * Please note that these values are used as indices to the rproc_handle_rsc
112		− * lookup table, so please keep them sane. Moreover, @RSC_LAST is used to
113		− * check the validity of an index before the lookup table is accessed, so
114		− * please update it as needed.
115		− */
116		−enum fw_resource_type {
117		− RSC_CARVEOUT = 0,
118		− RSC_DEVMEM = 1,
119		− RSC_TRACE = 2,
120		− RSC_VDEV = 3,
121		− RSC_LAST = 4,
122		− RSC_VENDOR_START = 128,
123		− RSC_VENDOR_END = 512,
124		−};
125		−
126		−#define FW_RSC_ADDR_ANY (-1)
127		−
128		−/**
129		− * struct fw_rsc_carveout - physically contiguous memory request
130		− * @da: device address
131		− * @pa: physical address
132		− * @len: length (in bytes)
133		− * @flags: iommu protection flags
134		− * @reserved: reserved (must be zero)
135		− * @name: human-readable name of the requested memory region
136		− *
137		− * This resource entry requests the host to allocate a physically contiguous
138		− * memory region.
139		− *
140		− * These request entries should precede other firmware resource entries,
141		− * as other entries might request placing other data objects inside
142		− * these memory regions (e.g. data/code segments, trace resource entries, ...).
143		− *
144		− * Allocating memory this way helps utilizing the reserved physical memory
145		− * (e.g. CMA) more efficiently, and also minimizes the number of TLB entries
146		− * needed to map it (in case @rproc is using an IOMMU). Reducing the TLB
147		− * pressure is important; it may have a substantial impact on performance.
148		− *
149		− * If the firmware is compiled with static addresses, then @da should specify
150		− * the expected device address of this memory region. If @da is set to
151		− * FW_RSC_ADDR_ANY, then the host will dynamically allocate it, and then
152		− * overwrite @da with the dynamically allocated address.
153		− *
154		− * We will always use @da to negotiate the device addresses, even if it
155		− * isn't using an iommu. In that case, though, it will obviously contain
156		− * physical addresses.
157		− *
158		− * Some remote processors needs to know the allocated physical address
159		− * even if they do use an iommu. This is needed, e.g., if they control
160		− * hardware accelerators which access the physical memory directly (this
161		− * is the case with OMAP4 for instance). In that case, the host will
162		− * overwrite @pa with the dynamically allocated physical address.
163		− * Generally we don't want to expose physical addresses if we don't have to
164		− * (remote processors are generally _not_ trusted), so we might want to
165		− * change this to happen _only_ when explicitly required by the hardware.
166		− *
167		− * @flags is used to provide IOMMU protection flags, and @name should
168		− * (optionally) contain a human readable name of this carveout region
169		− * (mainly for debugging purposes).
170		− */
171		−struct fw_rsc_carveout {
172		− u32 da;
173		− u32 pa;
174		− u32 len;
175		− u32 flags;
176		− u32 reserved;
177		− u8 name[32];
178		−} __packed;
179		−
180		−/**
181		− * struct fw_rsc_devmem - iommu mapping request
182		− * @da: device address
183		− * @pa: physical address
184		− * @len: length (in bytes)
185		− * @flags: iommu protection flags
186		− * @reserved: reserved (must be zero)
187		− * @name: human-readable name of the requested region to be mapped
188		− *
189		− * This resource entry requests the host to iommu map a physically contiguous
190		− * memory region. This is needed in case the remote processor requires
191		− * access to certain memory-based peripherals; _never_ use it to access
192		− * regular memory.
193		− *
194		− * This is obviously only needed if the remote processor is accessing memory
195		− * via an iommu.
196		− *
197		− * @da should specify the required device address, @pa should specify
198		− * the physical address we want to map, @len should specify the size of
199		− * the mapping and @flags is the IOMMU protection flags. As always, @name may
200		− * (optionally) contain a human readable name of this mapping (mainly for
201		− * debugging purposes).
202		− *
203		− * Note: at this point we just "trust" those devmem entries to contain valid
204		− * physical addresses, but this isn't safe and will be changed: eventually we
205		− * want remoteproc implementations to provide us ranges of physical addresses
206		− * the firmware is allowed to request, and not allow firmwares to request
207		− * access to physical addresses that are outside those ranges.
208		− */
209		−struct fw_rsc_devmem {
210		− u32 da;
211		− u32 pa;
212		− u32 len;
213		− u32 flags;
214		− u32 reserved;
215		− u8 name[32];
216		−} __packed;
217		−
218		−/**
219		− * struct fw_rsc_trace - trace buffer declaration
220		− * @da: device address
221		− * @len: length (in bytes)
222		− * @reserved: reserved (must be zero)
223		− * @name: human-readable name of the trace buffer
224		− *
225		− * This resource entry provides the host information about a trace buffer
226		− * into which the remote processor will write log messages.
227		− *
228		− * @da specifies the device address of the buffer, @len specifies
229		− * its size, and @name may contain a human readable name of the trace buffer.
230		− *
231		− * After booting the remote processor, the trace buffers are exposed to the
232		− * user via debugfs entries (called trace0, trace1, etc..).
233		− */
234		−struct fw_rsc_trace {
235		− u32 da;
236		− u32 len;
237		− u32 reserved;
238		− u8 name[32];
239		−} __packed;
240		−
241		−/**
242		− * struct fw_rsc_vdev_vring - vring descriptor entry
243		− * @da: device address
244		− * @align: the alignment between the consumer and producer parts of the vring
245		− * @num: num of buffers supported by this vring (must be power of two)
246		− * @notifyid: a unique rproc-wide notify index for this vring. This notify
247		− * index is used when kicking a remote processor, to let it know that this
248		− * vring is triggered.
249		− * @pa: physical address
250		− *
251		− * This descriptor is not a resource entry by itself; it is part of the
252		− * vdev resource type (see below).
253		− *
254		− * Note that @da should either contain the device address where
255		− * the remote processor is expecting the vring, or indicate that
256		− * dynamically allocation of the vring's device address is supported.
257		− */
258		−struct fw_rsc_vdev_vring {
259		− u32 da;
260		− u32 align;
261		− u32 num;
262		− u32 notifyid;
263		− u32 pa;
264		−} __packed;
265		−
266		−/**
267		− * struct fw_rsc_vdev - virtio device header
268		− * @id: virtio device id (as in virtio_ids.h)
269		− * @notifyid: a unique rproc-wide notify index for this vdev. This notify
270		− * index is used when kicking a remote processor, to let it know that the
271		− * status/features of this vdev have changes.
272		− * @dfeatures: specifies the virtio device features supported by the firmware
273		− * @gfeatures: a place holder used by the host to write back the
274		− * negotiated features that are supported by both sides.
275		− * @config_len: the size of the virtio config space of this vdev. The config
276		− * space lies in the resource table immediate after this vdev header.
277		− * @status: a place holder where the host will indicate its virtio progress.
278		− * @num_of_vrings: indicates how many vrings are described in this vdev header
279		− * @reserved: reserved (must be zero)
280		− * @vring: an array of @num_of_vrings entries of 'struct fw_rsc_vdev_vring'.
281		− *
282		− * This resource is a virtio device header: it provides information about
283		− * the vdev, and is then used by the host and its peer remote processors
284		− * to negotiate and share certain virtio properties.
285		− *
286		− * By providing this resource entry, the firmware essentially asks remoteproc
287		− * to statically allocate a vdev upon registration of the rproc (dynamic vdev
288		− * allocation is not yet supported).
289		− *
290		− * Note:
291		− * 1. unlike virtualization systems, the term 'host' here means
292		− * the Linux side which is running remoteproc to control the remote
293		− * processors. We use the name 'gfeatures' to comply with virtio's terms,
294		− * though there isn't really any virtualized guest OS here: it's the host
295		− * which is responsible for negotiating the final features.
296		− * Yeah, it's a bit confusing.
297		− *
298		− * 2. immediately following this structure is the virtio config space for
299		− * this vdev (which is specific to the vdev; for more info, read the virtio
300		− * spec). The size of the config space is specified by @config_len.
301		− */
302		−struct fw_rsc_vdev {
303		− u32 id;
304		− u32 notifyid;
305		− u32 dfeatures;
306		− u32 gfeatures;
307		− u32 config_len;
308		− u8 status;
309		− u8 num_of_vrings;
310		− u8 reserved[2];
311		− struct fw_rsc_vdev_vring vring[];
312		−} __packed;
	45	+#include <linux/rsc_table.h>
313	46
314	47	struct rproc;
315	48

include/linux/rsc_table.h+359−0

@@ -0,0 +1,359 @@
	1	+/*
	2	+ * Resource table and its types data structure
	3	+ *
	4	+ * Copyright(c) 2011 Texas Instruments, Inc.
	5	+ * Copyright(c) 2011 Google, Inc.
	6	+ * All rights reserved.
	7	+ *
	8	+ * Redistribution and use in source and binary forms, with or without
	9	+ * modification, are permitted provided that the following conditions
	10	+ * are met:
	11	+ *
	12	+ * * Redistributions of source code must retain the above copyright
	13	+ * notice, this list of conditions and the following disclaimer.
	14	+ * * Redistributions in binary form must reproduce the above copyright
	15	+ * notice, this list of conditions and the following disclaimer in
	16	+ * the documentation and/or other materials provided with the
	17	+ * distribution.
	18	+ * * Neither the name Texas Instruments nor the names of its
	19	+ * contributors may be used to endorse or promote products derived
	20	+ * from this software without specific prior written permission.
	21	+ *
	22	+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
	23	+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
	24	+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
	25	+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
	26	+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
	27	+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
	28	+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
	29	+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
	30	+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
	31	+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
	32	+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
	33	+ */
	34	+
	35	+#ifndef RSC_TABLE_H
	36	+#define RSC_TABLE_H
	37	+
	38	+/**
	39	+ * struct resource_table - firmware resource table header
	40	+ * @ver: version number
	41	+ * @num: number of resource entries
	42	+ * @reserved: reserved (must be zero)
	43	+ * @offset: array of offsets pointing at the various resource entries
	44	+ *
	45	+ * A resource table is essentially a list of system resources required
	46	+ * by the remote processor. It may also include configuration entries.
	47	+ * If needed, the remote processor firmware should contain this table
	48	+ * as a dedicated ".resource_table" ELF section.
	49	+ *
	50	+ * Some resources entries are mere announcements, where the host is informed
	51	+ * of specific remoteproc configuration. Other entries require the host to
	52	+ * do something (e.g. allocate a system resource). Sometimes a negotiation
	53	+ * is expected, where the firmware requests a resource, and once allocated,
	54	+ * the host should provide back its details (e.g. address of an allocated
	55	+ * memory region).
	56	+ *
	57	+ * The header of the resource table, as expressed by this structure,
	58	+ * contains a version number (should we need to change this format in the
	59	+ * future), the number of available resource entries, and their offsets
	60	+ * in the table.
	61	+ *
	62	+ * Immediately following this header are the resource entries themselves,
	63	+ * each of which begins with a resource entry header (as described below).
	64	+ */
	65	+struct resource_table {
	66	+ u32 ver;
	67	+ u32 num;
	68	+ u32 reserved[2];
	69	+ u32 offset[];
	70	+} __packed;
	71	+
	72	+/**
	73	+ * struct fw_rsc_hdr - firmware resource entry header
	74	+ * @type: resource type
	75	+ * @data: resource data
	76	+ *
	77	+ * Every resource entry begins with a 'struct fw_rsc_hdr' header providing
	78	+ * its @type. The content of the entry itself will immediately follow
	79	+ * this header, and it should be parsed according to the resource type.
	80	+ */
	81	+struct fw_rsc_hdr {
	82	+ u32 type;
	83	+ u8 data[];
	84	+} __packed;
	85	+
	86	+/**
	87	+ * enum fw_resource_type - types of resource entries
	88	+ *
	89	+ * @RSC_CARVEOUT: request for allocation of a physically contiguous
	90	+ * memory region.
	91	+ * @RSC_DEVMEM: request to iommu_map a memory-based peripheral.
	92	+ * @RSC_TRACE: announces the availability of a trace buffer into which
	93	+ * the remote processor will be writing logs.
	94	+ * @RSC_VDEV: declare support for a virtio device, and serve as its
	95	+ * virtio header.
	96	+ * @RSC_LAST: just keep this one at the end of standard resources
	97	+ * @RSC_VENDOR_START: start of the vendor specific resource types range
	98	+ * @RSC_VENDOR_END: end of the vendor specific resource types range
	99	+ *
	100	+ * For more details regarding a specific resource type, please see its
	101	+ * dedicated structure below.
	102	+ *
	103	+ * Please note that these values are used as indices to the rproc_handle_rsc
	104	+ * lookup table, so please keep them sane. Moreover, @RSC_LAST is used to
	105	+ * check the validity of an index before the lookup table is accessed, so
	106	+ * please update it as needed.
	107	+ */
	108	+enum fw_resource_type {
	109	+ RSC_CARVEOUT = 0,
	110	+ RSC_DEVMEM = 1,
	111	+ RSC_TRACE = 2,
	112	+ RSC_VDEV = 3,
	113	+ RSC_LAST = 4,
	114	+ RSC_VENDOR_START = 128,
	115	+ RSC_VENDOR_END = 512,
	116	+};
	117	+
	118	+#define FW_RSC_ADDR_ANY (-1)
	119	+
	120	+/**
	121	+ * struct fw_rsc_carveout - physically contiguous memory request
	122	+ * @da: device address
	123	+ * @pa: physical address
	124	+ * @len: length (in bytes)
	125	+ * @flags: iommu protection flags
	126	+ * @reserved: reserved (must be zero)
	127	+ * @name: human-readable name of the requested memory region
	128	+ *
	129	+ * This resource entry requests the host to allocate a physically contiguous
	130	+ * memory region.
	131	+ *
	132	+ * These request entries should precede other firmware resource entries,
	133	+ * as other entries might request placing other data objects inside
	134	+ * these memory regions (e.g. data/code segments, trace resource entries, ...).
	135	+ *
	136	+ * Allocating memory this way helps utilizing the reserved physical memory
	137	+ * (e.g. CMA) more efficiently, and also minimizes the number of TLB entries
	138	+ * needed to map it (in case @rproc is using an IOMMU). Reducing the TLB
	139	+ * pressure is important; it may have a substantial impact on performance.
	140	+ *
	141	+ * If the firmware is compiled with static addresses, then @da should specify
	142	+ * the expected device address of this memory region. If @da is set to
	143	+ * FW_RSC_ADDR_ANY, then the host will dynamically allocate it, and then
	144	+ * overwrite @da with the dynamically allocated address.
	145	+ *
	146	+ * We will always use @da to negotiate the device addresses, even if it
	147	+ * isn't using an iommu. In that case, though, it will obviously contain
	148	+ * physical addresses.
	149	+ *
	150	+ * Some remote processors needs to know the allocated physical address
	151	+ * even if they do use an iommu. This is needed, e.g., if they control
	152	+ * hardware accelerators which access the physical memory directly (this
	153	+ * is the case with OMAP4 for instance). In that case, the host will
	154	+ * overwrite @pa with the dynamically allocated physical address.
	155	+ * Generally we don't want to expose physical addresses if we don't have to
	156	+ * (remote processors are generally _not_ trusted), so we might want to
	157	+ * change this to happen _only_ when explicitly required by the hardware.
	158	+ *
	159	+ * @flags is used to provide IOMMU protection flags, and @name should
	160	+ * (optionally) contain a human readable name of this carveout region
	161	+ * (mainly for debugging purposes).
	162	+ */
	163	+struct fw_rsc_carveout {
	164	+ u32 da;
	165	+ u32 pa;
	166	+ u32 len;
	167	+ u32 flags;
	168	+ u32 reserved;
	169	+ u8 name[32];
	170	+} __packed;
	171	+
	172	+/**
	173	+ * struct fw_rsc_devmem - iommu mapping request
	174	+ * @da: device address
	175	+ * @pa: physical address
	176	+ * @len: length (in bytes)
	177	+ * @flags: iommu protection flags
	178	+ * @reserved: reserved (must be zero)
	179	+ * @name: human-readable name of the requested region to be mapped
	180	+ *
	181	+ * This resource entry requests the host to iommu map a physically contiguous
	182	+ * memory region. This is needed in case the remote processor requires
	183	+ * access to certain memory-based peripherals; _never_ use it to access
	184	+ * regular memory.
	185	+ *
	186	+ * This is obviously only needed if the remote processor is accessing memory
	187	+ * via an iommu.
	188	+ *
	189	+ * @da should specify the required device address, @pa should specify
	190	+ * the physical address we want to map, @len should specify the size of
	191	+ * the mapping and @flags is the IOMMU protection flags. As always, @name may
	192	+ * (optionally) contain a human readable name of this mapping (mainly for
	193	+ * debugging purposes).
	194	+ *
	195	+ * Note: at this point we just "trust" those devmem entries to contain valid
	196	+ * physical addresses, but this isn't safe and will be changed: eventually we
	197	+ * want remoteproc implementations to provide us ranges of physical addresses
	198	+ * the firmware is allowed to request, and not allow firmwares to request
	199	+ * access to physical addresses that are outside those ranges.
	200	+ */
	201	+struct fw_rsc_devmem {
	202	+ u32 da;
	203	+ u32 pa;
	204	+ u32 len;
	205	+ u32 flags;
	206	+ u32 reserved;
	207	+ u8 name[32];
	208	+} __packed;
	209	+
	210	+/**
	211	+ * struct fw_rsc_trace - trace buffer declaration
	212	+ * @da: device address
	213	+ * @len: length (in bytes)
	214	+ * @reserved: reserved (must be zero)
	215	+ * @name: human-readable name of the trace buffer
	216	+ *
	217	+ * This resource entry provides the host information about a trace buffer
	218	+ * into which the remote processor will write log messages.
	219	+ *
	220	+ * @da specifies the device address of the buffer, @len specifies
	221	+ * its size, and @name may contain a human readable name of the trace buffer.
	222	+ *
	223	+ * After booting the remote processor, the trace buffers are exposed to the
	224	+ * user via debugfs entries (called trace0, trace1, etc..).
	225	+ */
	226	+struct fw_rsc_trace {
	227	+ u32 da;
	228	+ u32 len;
	229	+ u32 reserved;
	230	+ u8 name[32];
	231	+} __packed;
	232	+
	233	+/**
	234	+ * struct fw_rsc_vdev_vring - vring descriptor entry
	235	+ * @da: device address
	236	+ * @align: the alignment between the consumer and producer parts of the vring
	237	+ * @num: num of buffers supported by this vring (must be power of two)
	238	+ * @notifyid: a unique rproc-wide notify index for this vring. This notify
	239	+ * index is used when kicking a remote processor, to let it know that this
	240	+ * vring is triggered.
	241	+ * @pa: physical address
	242	+ *
	243	+ * This descriptor is not a resource entry by itself; it is part of the
	244	+ * vdev resource type (see below).
	245	+ *
	246	+ * Note that @da should either contain the device address where
	247	+ * the remote processor is expecting the vring, or indicate that
	248	+ * dynamically allocation of the vring's device address is supported.
	249	+ */
	250	+struct fw_rsc_vdev_vring {
	251	+ u32 da;
	252	+ u32 align;
	253	+ u32 num;
	254	+ u32 notifyid;
	255	+ u32 pa;
	256	+} __packed;
	257	+
	258	+/**
	259	+ * struct fw_rsc_vdev - virtio device header
	260	+ * @id: virtio device id (as in virtio_ids.h)
	261	+ * @notifyid: a unique rproc-wide notify index for this vdev. This notify
	262	+ * index is used when kicking a remote processor, to let it know that the
	263	+ * status/features of this vdev have changes.
	264	+ * @dfeatures: specifies the virtio device features supported by the firmware
	265	+ * @gfeatures: a place holder used by the host to write back the
	266	+ * negotiated features that are supported by both sides.
	267	+ * @config_len: the size of the virtio config space of this vdev. The config
	268	+ * space lies in the resource table immediate after this vdev header.
	269	+ * @status: a place holder where the host will indicate its virtio progress.
	270	+ * @num_of_vrings: indicates how many vrings are described in this vdev header
	271	+ * @reserved: reserved (must be zero)
	272	+ * @vring: an array of @num_of_vrings entries of 'struct fw_rsc_vdev_vring'.
	273	+ *
	274	+ * This resource is a virtio device header: it provides information about
	275	+ * the vdev, and is then used by the host and its peer remote processors
	276	+ * to negotiate and share certain virtio properties.
	277	+ *
	278	+ * By providing this resource entry, the firmware essentially asks remoteproc
	279	+ * to statically allocate a vdev upon registration of the rproc (dynamic vdev
	280	+ * allocation is not yet supported).
	281	+ *
	282	+ * Note:
	283	+ * 1. unlike virtualization systems, the term 'host' here means
	284	+ * the Linux side which is running remoteproc to control the remote
	285	+ * processors. We use the name 'gfeatures' to comply with virtio's terms,
	286	+ * though there isn't really any virtualized guest OS here: it's the host
	287	+ * which is responsible for negotiating the final features.
	288	+ * Yeah, it's a bit confusing.
	289	+ *
	290	+ * 2. immediately following this structure is the virtio config space for
	291	+ * this vdev (which is specific to the vdev; for more info, read the virtio
	292	+ * spec). The size of the config space is specified by @config_len.
	293	+ */
	294	+struct fw_rsc_vdev {
	295	+ u32 id;
	296	+ u32 notifyid;
	297	+ u32 dfeatures;
	298	+ u32 gfeatures;
	299	+ u32 config_len;
	300	+ u8 status;
	301	+ u8 num_of_vrings;
	302	+ u8 reserved[2];
	303	+ struct fw_rsc_vdev_vring vring[];
	304	+} __packed;
	305	+
	306	+/**
	307	+ * rsc_table_for_each_entry() - iterate over all entries in a resource table
	308	+ * @table: pointer to the resource table
	309	+ * @table_sz: total size of the table buffer in bytes
	310	+ * @dev: device used for error logging
	311	+ * @cb: callback invoked for each entry:
	312	+ * @type - value from enum fw_resource_type
	313	+ * @rsc - pointer to the entry payload (past struct fw_rsc_hdr)
	314	+ * @offset - byte offset of the payload within the table; callers
	315	+ * that write back into the table (e.g. to record a
	316	+ * dynamically allocated address) use this to locate the
	317	+ * entry for later update
	318	+ * @avail - bytes available in the payload
	319	+ * @data - caller-supplied private pointer
	320	+ * Return 0 to continue iteration, non-zero to stop.
	321	+ * @data: private pointer forwarded to @cb on every call
	322	+ *
	323	+ * Iterates over every resource entry in @table, performing the standard
	324	+ * truncation check, and invokes @cb for each one. Iteration stops on the
	325	+ * first non-zero return from @cb or on a malformed table.
	326	+ *
	327	+ * Returns 0 after a complete iteration, -EINVAL if the table is truncated,
	328	+ * or the first non-zero value returned by @cb.
	329	+ */
	330	+static inline int rsc_table_for_each_entry(struct resource_table *table,
	331	+ size_t table_sz,
	332	+ struct device *dev,
	333	+ int (cb)(u32 type, void rsc,
	334	+ int offset, int avail,
	335	+ void *data),
	336	+ void *data) {
	337	+ int i, ret;
	338	+
	339	+ for (i = 0; i < table->num; i++) {
	340	+ int offset = table->offset[i];
	341	+ struct fw_rsc_hdr hdr = (void )table + offset;
	342	+ int avail = table_sz - offset - sizeof(*hdr);
	343	+ int rsc_offset = offset + sizeof(*hdr);
	344	+ void rsc = (void )hdr + sizeof(*hdr);
	345	+
	346	+ if (avail < 0) {
	347	+ dev_err(dev, "rsc table is truncated\n");
	348	+ return -EINVAL;
	349	+ }
	350	+
	351	+ ret = cb(hdr->type, rsc, rsc_offset, avail, data);
	352	+ if (ret)
	353	+ return ret;
	354	+ }
	355	+
	356	+ return 0;
	357	+}
	358	+
	359	+#endif /* RSC_TABLE_H */

Merge tag 'rproc-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux

Keyboard shortcuts

General

Issues and pull requests

Issues, pull requests and Inbox

Repository code