On Thu, Oct 24, 2024 at 11:17:40AM -0700, anish kumar wrote:
> On Thu, Oct 24, 2024 at 8:53 AM Mathieu Poirier
> <mathieu.poirier@xxxxxxxxxx> wrote:
> >
> > On Tue, Oct 22, 2024 at 10:33:53PM -0700, anish kumar wrote:
> > > Added following changes:
> > > 1. Components provided by remoteproc framework.
> > > 2. Remoteproc driver responsibilities.
> > > 3. Remoteproc framework responsibilities.
> > > 4. Better explanation of how to ask for resources
> > > from the framework by the remote processor.
> > >
> > > Signed-off-by: anish kumar <yesanishhere@xxxxxxxxx>
> > > ---
> > > .../driver-api/remoteproc/remoteproc.rst | 596 +++++++-----------
> > > 1 file changed, 243 insertions(+), 353 deletions(-)
> > >
> > > diff --git a/Documentation/driver-api/remoteproc/remoteproc.rst b/Documentation/driver-api/remoteproc/remoteproc.rst
> > > index 9cccd3dd6a4b..7ca545eea153 100644
> > > --- a/Documentation/driver-api/remoteproc/remoteproc.rst
> > > +++ b/Documentation/driver-api/remoteproc/remoteproc.rst
> > > @@ -1,359 +1,249 @@
> > > +.. SPDX-License-Identifier: GPL-2.0
> > > +
> > > ==========================
> > > Remote Processor Framework
> > > ==========================
> > >
> > > -Introduction
> > > -============
> > > -
> > > -Modern SoCs typically have heterogeneous remote processor devices in asymmetric
> > > -multiprocessing (AMP) configurations, which may be running different instances
> > > -of operating system, whether it's Linux or any other flavor of real-time OS.
> > > -
> > > -OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP.
> > > -In a typical configuration, the dual cortex-A9 is running Linux in a SMP
> > > -configuration, and each of the other three cores (two M3 cores and a DSP)
> > > -is running its own instance of RTOS in an AMP configuration.
> > > -
> > > -The remoteproc framework allows different platforms/architectures to
> > > -control (power on, load firmware, power off) those remote processors while
> > > -abstracting the hardware differences, so the entire driver doesn't need to be
> > > -duplicated. In addition, this framework also adds rpmsg virtio devices
> > > -for remote processors that supports this kind of communication. This way,
> > > -platform-specific remoteproc drivers only need to provide a few low-level
> > > -handlers, and then all rpmsg drivers will then just work
> > > -(for more information about the virtio-based rpmsg bus and its drivers,
> > > -please read Documentation/staging/rpmsg.rst).
> > > -Registration of other types of virtio devices is now also possible. Firmwares
> > > -just need to publish what kind of virtio devices do they support, and then
> > > -remoteproc will add those devices. This makes it possible to reuse the
> > > -existing virtio drivers with remote processor backends at a minimal development
> > > -cost.
> > > -
> > > -User API
> > > -========
> > > -
> > > -::
> > > -
> > > - int rproc_boot(struct rproc *rproc)
> > > -
> > > -Boot a remote processor (i.e. load its firmware, power it on, ...).
> > > -
> > > -If the remote processor is already powered on, this function immediately
> > > -returns (successfully).
> > > -
> > > -Returns 0 on success, and an appropriate error value otherwise.
> > > -Note: to use this function you should already have a valid rproc
> > > -handle. There are several ways to achieve that cleanly (devres, pdata,
> > > -the way remoteproc_rpmsg.c does this, or, if this becomes prevalent, we
> > > -might also consider using dev_archdata for this).
> > > -
> > > -::
> > > -
> > > - void rproc_shutdown(struct rproc *rproc)
> > > -
> > > -Power off a remote processor (previously booted with rproc_boot()).
> > > -In case @rproc is still being used by an additional user(s), then
> > > -this function will just decrement the power refcount and exit,
> > > -without really powering off the device.
> > > -
> > > -Every call to rproc_boot() must (eventually) be accompanied by a call
> > > -to rproc_shutdown(). Calling rproc_shutdown() redundantly is a bug.
> > > -
> > > -.. note::
> > > -
> > > - we're not decrementing the rproc's refcount, only the power refcount.
> > > - which means that the @rproc handle stays valid even after
> > > - rproc_shutdown() returns, and users can still use it with a subsequent
> > > - rproc_boot(), if needed.
> > > -
> > > -::
> > > -
> > > - struct rproc *rproc_get_by_phandle(phandle phandle)
> > > -
> > > -Find an rproc handle using a device tree phandle. Returns the rproc
> > > -handle on success, and NULL on failure. This function increments
> > > -the remote processor's refcount, so always use rproc_put() to
> > > -decrement it back once rproc isn't needed anymore.
> > > -
> > > -Typical usage
> > > -=============
> > > -
> > > -::
> > > -
> > > - #include <linux/remoteproc.h>
> > > -
> > > - /* in case we were given a valid 'rproc' handle */
> > > - int dummy_rproc_example(struct rproc *my_rproc)
> > > - {
> > > - int ret;
> > > -
> > > - /* let's power on and boot our remote processor */
> > > - ret = rproc_boot(my_rproc);
> > > - if (ret) {
> > > - /*
> > > - * something went wrong. handle it and leave.
> > > - */
> > > - }
> > > -
> > > - /*
> > > - * our remote processor is now powered on... give it some work
> > > - */
> > > -
> > > - /* let's shut it down now */
> > > - rproc_shutdown(my_rproc);
> > > - }
> > > -
> > > -API for implementors
> > > -====================
> > > -
> > > -::
> > > -
> > > - struct rproc *rproc_alloc(struct device *dev, const char *name,
> > > - const struct rproc_ops *ops,
> > > - const char *firmware, int len)
> > > -
> > > -Allocate a new remote processor handle, but don't register
> > > -it yet. Required parameters are the underlying device, the
> > > -name of this remote processor, platform-specific ops handlers,
> > > -the name of the firmware to boot this rproc with, and the
> > > -length of private data needed by the allocating rproc driver (in bytes).
> > > -
> > > -This function should be used by rproc implementations during
> > > -initialization of the remote processor.
> > > -
> > > -After creating an rproc handle using this function, and when ready,
> > > -implementations should then call rproc_add() to complete
> > > -the registration of the remote processor.
> > > -
> > > -On success, the new rproc is returned, and on failure, NULL.
> > > -
> > > -.. note::
> > > -
> > > - **never** directly deallocate @rproc, even if it was not registered
> > > - yet. Instead, when you need to unroll rproc_alloc(), use rproc_free().
> > > -
> > > -::
> > > -
> > > - void rproc_free(struct rproc *rproc)
> > > -
> > > -Free an rproc handle that was allocated by rproc_alloc.
> > > -
> > > -This function essentially unrolls rproc_alloc(), by decrementing the
> > > -rproc's refcount. It doesn't directly free rproc; that would happen
> > > -only if there are no other references to rproc and its refcount now
> > > -dropped to zero.
> > > -
> > > -::
> > > -
> > > - int rproc_add(struct rproc *rproc)
> > > -
> > > -Register @rproc with the remoteproc framework, after it has been
> > > -allocated with rproc_alloc().
> > > -
> > > -This is called by the platform-specific rproc implementation, whenever
> > > -a new remote processor device is probed.
> > > -
> > > -Returns 0 on success and an appropriate error code otherwise.
> > > -Note: this function initiates an asynchronous firmware loading
> > > -context, which will look for virtio devices supported by the rproc's
> > > -firmware.
> > > -
> > > -If found, those virtio devices will be created and added, so as a result
> > > -of registering this remote processor, additional virtio drivers might get
> > > -probed.
> > > -
> > > -::
> > > -
> > > - int rproc_del(struct rproc *rproc)
> > > -
> > > -Unroll rproc_add().
> > > -
> > > -This function should be called when the platform specific rproc
> > > -implementation decides to remove the rproc device. it should
> > > -_only_ be called if a previous invocation of rproc_add()
> > > -has completed successfully.
> > > -
> > > -After rproc_del() returns, @rproc is still valid, and its
> > > -last refcount should be decremented by calling rproc_free().
> > > -
> > > -Returns 0 on success and -EINVAL if @rproc isn't valid.
> > > -
> > > -::
> > > -
> > > - void rproc_report_crash(struct rproc *rproc, enum rproc_crash_type type)
> > > -
> > > -Report a crash in a remoteproc
> > > -
> > > -This function must be called every time a crash is detected by the
> > > -platform specific rproc implementation. This should not be called from a
> > > -non-remoteproc driver. This function can be called from atomic/interrupt
> > > -context.
> > > -
> > > -Implementation callbacks
> > > +.. Contents:
> > > +
> > > + 1. Introduction
> > > + 2. Remoteproc framework responsibilities
> > > + 3. Remoteproc driver responsibilities
> > > + 4. Virtio and rpmsg
> > > +
> > > +1. Introduction
> > > +===============
> > > +
> > > +Modern System on Chips (SoCs) typically integrate heterogeneous remote
> > > +processor devices in asymmetric multiprocessing (AMP) configurations.
> > > +These processors may run different operating systems, such as Linux and
> > > +various real-time operating systems (RTOS).
> >
> > You are moving things around _and_ making modifications to the text in the same
> > patch, something I specifically asked not to do. Moreover, the above conveys
>
> Sorry for doing that, I thought I moved the file first as you instructed but
> I didn't understand that I should also not reword the sentences that convey
> the same meaning. Will keep the text of below content in the same file:
> 1. Introduction
> 2. Binary Firmware Structure: will just add example as shown in this patch.
> 3. Virtio and remoteproc: didn't change anything in the patch for this.
We don't seem to understand each other - the "Virtio and remoteproc" section is
the first thing I red and what made me aware of the rewording.
>
> For below:
> 1. User API:
> 2. Typical usage:
> 3. API for implementors :
>
> Should I just move all of the above text as it is to
> remoteproc-kernel-api.rst or
> you prefer here as I feel it belongs there?
I have looked at other subsystems documented under Documentation/driver-api and
I can't find instances of the type [subsystem]-kernel-api.rst. As such I don't
see what is so special about remoteproc that it would mandate adding a new file.
Why can't it just be in a single file like most subsystems do?
>
> > exactly the same information as found in [1] but using different words. I
> > am in favour of enhancing documentation but not creating unneeded churn.
> >
> > I found several instances of the same rewording pattern in the sections below.
> > As such I will not look at the other patches nor move forward with this set.
> >
> > Thanks,
> > Mathieu
>
> Thanks Mathieu, for reviewing and providing feedback as always.
>
> >
> > [1]. https://elixir.bootlin.com/linux/v6.12-rc4/source/Documentation/staging/remoteproc.rst
> >
> > > +
> > > +For example, the OMAP4 platform features dual Cortex-A9 cores, dual
> > > +Cortex-M3 cores, and a C64x+ DSP. In a standard setup, the Cortex-A9
> > > +cores execute Linux in a symmetric multiprocessing (SMP) configuration,
> > > +while the M3 cores and DSP run independent instances of an RTOS.
> > > +
> > > +The remoteproc framework allows various platforms and architectures to
> > > +manage remote processors, including operations such as powering on,
> > > +loading firmware, and powering off. This framework abstracts hardware
> > > +differences, promoting code reuse and minimizing duplication. It also
> > > +supports rpmsg virtio devices for remote processors that utilize this
> > > +communication method. Consequently, platform-specific remoteproc drivers
> > > +need only implement a few low-level handlers, enabling seamless operation
> > > +of all rpmsg drivers. (For more details about the virtio-based rpmsg
> > > +bus and its drivers, refer to rpmsg documentation.)
> > > +
> > > +Additionally, the framework allows for the registration of various
> > > +virtio devices. Firmware can publish the types of virtio devices it
> > > +supports, facilitating their addition to the remoteproc framework. This
> > > +flexibility enables the reuse of existing virtio drivers with remote
> > > +processor backends at minimal development cost.
> > > +
> > > +The primary purpose of the remoteproc framework is to download firmware
> > > +for remote processors and manage their lifecycle. The framework consists
> > > +of several key components:
> > > +
> > > +- **Character Driver**: Provides userspace access to control the remote
> > > + processor.
> > > +- **ELF Utility**: Offers functions for handling ELF files and managing
> > > + resources requested by the remote processor.
> > > +- **Remoteproc Core**: Manages firmware downloads and recovery actions
> > > + in case of a remote processor crash.
> > > +- **Coredump**: Provides facilities for coredumping and tracing from
> > > + the remote processor in the event of a crash.
> > > +- **Userspace Interaction**: Uses sysfs and debugfs to manage the
> > > + lifecycle and status of the remote processor.
> > > +- **Virtio Support**: Facilitates interaction with the virtio and
> > > + rpmsg bus.
> > > +
> > > +From here on, references to "framework" denote the remoteproc
> > > +framework, and "driver" refers to the remoteproc driver that utilizes
> > > +the framework for managing remote processors.
> > > +
> > > +2. Remoteproc framework Responsibilities
> > > +========================================
> > > +
> > > +The framework begins by gathering information about the firmware file
> > > +to be downloaded through the request_firmware function. It supports
> > > +the ELF format and parses the firmware image to identify the physical
> > > +addresses that need to be populated from the corresponding ELF sections.
> > > +The framework also requires knowledge of the logical or I/O-mapped
> > > +addresses in the application processor. Once this information is
> > > +obtained from the driver, the framework transfers the data to the
> > > +specified addresses and starts the remote, along with
> > > +any devices physically or logically connected to it.
> > > +
> > > +Dependent devices, referred to as `subdevices` within the framework,
> > > +are also managed post-registration by their respective drivers.
> > > +Subdevices can register themselves using `rproc_(add/remove)_subdev`.
> > > +Non-remoteproc drivers can use subdevices as a way to logically connect
> > > +to remote and get lifecycle notifications of the remote.
> > > +
> > > +The framework oversees the lifecycle of the remote and
> > > +provides the `rproc_report_crash` function, which the driver invokes
> > > +upon receiving a crash notification from the remote. The
> > > +notification method can differ based on the design of the remote
> > > +processor and its communication with the application processor. For
> > > +instance, if the remote is a DSP equipped with a watchdog,
> > > +unresponsive behavior triggers the watchdog, generating an interrupt
> > > +that routes to the application processor, allowing it to call
> > > +`rproc_report_crash` in the driver's interrupt context.
> > > +
> > > +During crash handling, the framework performs the following actions:
> > > +
> > > +a. Sends a request to stop the remote and any connected or
> > > + dependent subdevices.
> > > +b. Generates a coredump, dumping all `resources` requested by the
> > > + remote alongside relevant debugging information. Resources are
> > > + explained below.
> > > +c. Reloads the firmware and restarts the remote.
> > > +
> > > +If the `RPROC_FEAT_ATTACH_ON_RECOVERY` flag is set, the detach and
> > > +attach callbacks of the driver are invoked without reloading the
> > > +firmware. This is useful when the remote requires no
> > > +assistance for recovery, or when the application processor can restart
> > > +independently. After recovery, the application processor can reattach
> > > +to the remote.
> > > +
> > > +The remote can request resources from the framework, which
> > > +allocates a ".resource_table" section. During the ELF parsing phase,
> > > +the framework identifies this section and calls the appropriate
> > > +handler to allocate the requested resources.
> > > +
> > > +Resource management within the framework can accommodate any type of
> > > +`fw_resource_type`.
> > > +
> > > +.. code-block:: c
> > > +
> > > + enum fw_resource_type {
> > > + RSC_CARVEOUT = 0,
> > > + RSC_DEVMEM = 1,
> > > + RSC_TRACE = 2,
> > > + RSC_VDEV = 3,
> > > + RSC_LAST = 4,
> > > + RSC_VENDOR_START = 128,
> > > + RSC_VENDOR_END = 512,
> > > + };
> > > +
> > > + struct resource_table {
> > > + u32 ver;
> > > + u32 num;
> > > + u32 reserved[2];
> > > + u32 offset[];
> > > + } __packed;
> > > +
> > > + struct fw_rsc_hdr {
> > > + u32 type;
> > > + u8 data[];
> > > + } __packed;
> > > +
> > > +For example, if the remote requests both `RSC_TRACE` and
> > > +`RSC_CARVEOUT` for memory allocation, the ELF firmware can be structured
> > > +as follows:
> > > +
> > > +.. code-block:: c
> > > +
> > > + #define MAX_SHARED_RESOURCE 2
> > > + #define LOG_BUF_SIZE 1000
> > > + #define CARVEOUT_DUMP_PA 0x12345678
> > > + #define CARVEOUT_DUMP_SIZE 2000
> > > +
> > > + struct shared_resource_table {
> > > + u32 ver;
> > > + u32 num;
> > > + u32 reserved[2];
> > > + u32 offset[MAX_SHARED_RESOURCE];
> > > + struct fw_rsc_trace log_trace;
> > > + struct fw_rsc_carveout dump_carveout;
> > > + };
> > > +
> > > + volatile struct shared_resource_table table = {
> > > + .ver = 1,
> > > + .num = 2,
> > > + .reserved = {0, 0},
> > > + .offset = {
> > > + offsetof(struct resource_table, log_trace),
> > > + offsetof(struct resource_table, dump_carveout),
> > > + },
> > > + .log_trace = {
> > > + RSC_TRACE,
> > > + (u32)log_buf, LOG_BUF_SIZE, 0, "log_trace",
> > > + },
> > > + .dump_carveout = {
> > > + RSC_CARVEOUT,
> > > + (u32)FW_RSC_ADDR_ANY, CARVEOUT_PA, 0, "carveout_dump",
> > > + },
> > > + };
> > > +
> > > +The framework creates a sysfs file when it encounters the `RSC_TRACE`
> > > +type to expose log information to userspace. Other resource types are
> > > +handled accordingly. In the example above, `CARVEOUT_DUMP_SIZE` bytes
> > > +of DMA memory will be allocated starting from `CARVEOUT_DUMP_PA`.
> > > +
> > > +
> > > +3. Remoteproc driver responsibilities
> > > +=====================================
> > > +
> > > +The driver must provide the following information to the core:
> > > +
> > > +a. Translate device addresses (physical addresses) found in the ELF
> > > + firmware to virtual addresses in Linux using the `da_to_va`
> > > + callback. This allows the framework to copy ELF firmware from the
> > > + filesystem to the addresses expected by the remote since
> > > + the framework cannot directly access those physical addresses.
> > > +b. Prepare/unprepare the remote prior to firmware loading,
> > > + which may involve allocating carveout and reserved memory regions.
> > > +c. Implement methods for starting and stopping the remote,
> > > + whether by setting registers or sending explicit interrupts,
> > > + depending on the hardware design.
> > > +d. Provide attach and detach callbacks to start the remote
> > > + without loading the firmware. This is beneficial when the remote
> > > + processor is already loaded and running.
> > > +e. Implement a load callback for firmware loading, typically using
> > > + the ELF loader provided by the framework; currently, only ELF
> > > + format is supported.
> > > +f. Invoke the framework's crash handler API upon detecting a remote
> > > + crash.
> > > +
> > > +Drivers must fill the `rproc_ops` structure and call `rproc_alloc`
> > > +to register themselves with the framework.
> > > +
> > > +.. code-block:: c
> > > +
> > > + struct rproc_ops {
> > > + int (*prepare)(struct rproc *rproc);
> > > + int (*unprepare)(struct rproc *rproc);
> > > + int (*start)(struct rproc *rproc);
> > > + int (*stop)(struct rproc *rproc);
> > > + int (*attach)(struct rproc *rproc);
> > > + int (*detach)(struct rproc *rproc);
> > > + void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len,
> > > + bool *is_iomem);
> > > + int (*parse_fw)(struct rproc *rproc, const struct firmware *fw);
> > > + int (*handle_rsc)(struct rproc *rproc, u32 rsc_type,
> > > + void *rsc, int offset, int avail);
> > > + int (*load)(struct rproc *rproc, const struct firmware *fw);
> > > + //snip
> > > + };
> > > +
> > > +
> > > +4. Virtio and Remoteproc
> > > ========================
> > >
> > > -These callbacks should be provided by platform-specific remoteproc
> > > -drivers::
> > > -
> > > - /**
> > > - * struct rproc_ops - platform-specific device handlers
> > > - * @start: power on the device and boot it
> > > - * @stop: power off the device
> > > - * @kick: kick a virtqueue (virtqueue id given as a parameter)
> > > - */
> > > - struct rproc_ops {
> > > - int (*start)(struct rproc *rproc);
> > > - int (*stop)(struct rproc *rproc);
> > > - void (*kick)(struct rproc *rproc, int vqid);
> > > - };
> > > -
> > > -Every remoteproc implementation should at least provide the ->start and ->stop
> > > -handlers. If rpmsg/virtio functionality is also desired, then the ->kick handler
> > > -should be provided as well.
> > > -
> > > -The ->start() handler takes an rproc handle and should then power on the
> > > -device and boot it (use rproc->priv to access platform-specific private data).
> > > -The boot address, in case needed, can be found in rproc->bootaddr (remoteproc
> > > -core puts there the ELF entry point).
> > > -On success, 0 should be returned, and on failure, an appropriate error code.
> > > -
> > > -The ->stop() handler takes an rproc handle and powers the device down.
> > > -On success, 0 is returned, and on failure, an appropriate error code.
> > > -
> > > -The ->kick() handler takes an rproc handle, and an index of a virtqueue
> > > -where new message was placed in. Implementations should interrupt the remote
> > > -processor and let it know it has pending messages. Notifying remote processors
> > > -the exact virtqueue index to look in is optional: it is easy (and not
> > > -too expensive) to go through the existing virtqueues and look for new buffers
> > > -in the used rings.
> > > -
> > > -Binary Firmware Structure
> > > -=========================
> > > -
> > > -At this point remoteproc supports ELF32 and ELF64 firmware binaries. However,
> > > -it is quite expected that other platforms/devices which we'd want to
> > > -support with this framework will be based on different binary formats.
> > > -
> > > -When those use cases show up, we will have to decouple the binary format
> > > -from the framework core, so we can support several binary formats without
> > > -duplicating common code.
> > > -
> > > -When the firmware is parsed, its various segments are loaded to memory
> > > -according to the specified device address (might be a physical address
> > > -if the remote processor is accessing memory directly).
> > > -
> > > -In addition to the standard ELF segments, most remote processors would
> > > -also include a special section which we call "the resource table".
> > > -
> > > -The resource table contains system resources that the remote processor
> > > -requires before it should be powered on, such as allocation of physically
> > > -contiguous memory, or iommu mapping of certain on-chip peripherals.
> > > -Remotecore will only power up the device after all the resource table's
> > > -requirement are met.
> > > -
> > > -In addition to system resources, the resource table may also contain
> > > -resource entries that publish the existence of supported features
> > > -or configurations by the remote processor, such as trace buffers and
> > > -supported virtio devices (and their configurations).
> > > -
> > > -The resource table begins with this header::
> > > -
> > > - /**
> > > - * struct resource_table - firmware resource table header
> > > - * @ver: version number
> > > - * @num: number of resource entries
> > > - * @reserved: reserved (must be zero)
> > > - * @offset: array of offsets pointing at the various resource entries
> > > - *
> > > - * The header of the resource table, as expressed by this structure,
> > > - * contains a version number (should we need to change this format in the
> > > - * future), the number of available resource entries, and their offsets
> > > - * in the table.
> > > - */
> > > - struct resource_table {
> > > - u32 ver;
> > > - u32 num;
> > > - u32 reserved[2];
> > > - u32 offset[0];
> > > - } __packed;
> > > -
> > > -Immediately following this header are the resource entries themselves,
> > > -each of which begins with the following resource entry header::
> > > -
> > > - /**
> > > - * struct fw_rsc_hdr - firmware resource entry header
> > > - * @type: resource type
> > > - * @data: resource data
> > > - *
> > > - * Every resource entry begins with a 'struct fw_rsc_hdr' header providing
> > > - * its @type. The content of the entry itself will immediately follow
> > > - * this header, and it should be parsed according to the resource type.
> > > - */
> > > - struct fw_rsc_hdr {
> > > - u32 type;
> > > - u8 data[0];
> > > - } __packed;
> > > -
> > > -Some resources entries are mere announcements, where the host is informed
> > > -of specific remoteproc configuration. Other entries require the host to
> > > -do something (e.g. allocate a system resource). Sometimes a negotiation
> > > -is expected, where the firmware requests a resource, and once allocated,
> > > -the host should provide back its details (e.g. address of an allocated
> > > -memory region).
> > > -
> > > -Here are the various resource types that are currently supported::
> > > -
> > > - /**
> > > - * enum fw_resource_type - types of resource entries
> > > - *
> > > - * @RSC_CARVEOUT: request for allocation of a physically contiguous
> > > - * memory region.
> > > - * @RSC_DEVMEM: request to iommu_map a memory-based peripheral.
> > > - * @RSC_TRACE: announces the availability of a trace buffer into which
> > > - * the remote processor will be writing logs.
> > > - * @RSC_VDEV: declare support for a virtio device, and serve as its
> > > - * virtio header.
> > > - * @RSC_LAST: just keep this one at the end
> > > - * @RSC_VENDOR_START: start of the vendor specific resource types range
> > > - * @RSC_VENDOR_END: end of the vendor specific resource types range
> > > - *
> > > - * Please note that these values are used as indices to the rproc_handle_rsc
> > > - * lookup table, so please keep them sane. Moreover, @RSC_LAST is used to
> > > - * check the validity of an index before the lookup table is accessed, so
> > > - * please update it as needed.
> > > - */
> > > - enum fw_resource_type {
> > > - RSC_CARVEOUT = 0,
> > > - RSC_DEVMEM = 1,
> > > - RSC_TRACE = 2,
> > > - RSC_VDEV = 3,
> > > - RSC_LAST = 4,
> > > - RSC_VENDOR_START = 128,
> > > - RSC_VENDOR_END = 512,
> > > - };
> > > -
> > > -For more details regarding a specific resource type, please see its
> > > -dedicated structure in include/linux/remoteproc.h.
> > > -
> > > -We also expect that platform-specific resource entries will show up
> > > -at some point. When that happens, we could easily add a new RSC_PLATFORM
> > > -type, and hand those resources to the platform-specific rproc driver to handle.
> > > -
> > > -Virtio and remoteproc
> > > -=====================
> > > -
> > > -The firmware should provide remoteproc information about virtio devices
> > > -that it supports, and their configurations: a RSC_VDEV resource entry
> > > -should specify the virtio device id (as in virtio_ids.h), virtio features,
> > > -virtio config space, vrings information, etc.
> > > -
> > > -When a new remote processor is registered, the remoteproc framework
> > > -will look for its resource table and will register the virtio devices
> > > -it supports. A firmware may support any number of virtio devices, and
> > > -of any type (a single remote processor can also easily support several
> > > -rpmsg virtio devices this way, if desired).
> > > -
> > > -Of course, RSC_VDEV resource entries are only good enough for static
> > > -allocation of virtio devices. Dynamic allocations will also be made possible
> > > -using the rpmsg bus (similar to how we already do dynamic allocations of
> > > -rpmsg channels; read more about it in rpmsg.txt).
> > > +The firmware must provide remoteproc with information regarding the
> > > +virtio devices it supports and their configurations: an `RSC_VDEV`
> > > +resource entry should detail the virtio device ID (as defined in
> > > +`virtio_ids.h`), virtio features, virtio config space, vrings
> > > +information, etc.
> > > +
> > > +Upon registration of a new remote, the remoteproc framework
> > > +searches for its resource table and registers the supported virtio
> > > +devices. A firmware may support multiple virtio devices, of various
> > > +types (a single remote can support multiple rpmsg virtio
> > > +devices if required).
> > > +
> > > +Moreover, `RSC_VDEV` resource entries suffice for static allocation
> > > +of virtio devices. Dynamic allocations will also be supported using
> > > +the rpmsg bus, akin to the handling of dynamic allocations for rpmsg
> > > +channels. For more information, refer to rpmsg documentation.
> > > --
> > > 2.39.3 (Apple Git-146)
> > >
