Messages in this thread | | | Date | Thu, 9 May 2024 11:27:04 -0500 | Subject | Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem | From | Andrew Davis <> |
| |
On 5/9/24 10:32 AM, Mathieu Poirier wrote: > On Wed, 8 May 2024 at 10:54, Andrew Davis <afd@ti.com> wrote: >> >> On 5/7/24 3:36 PM, Mathieu Poirier wrote: >>> On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote: >>>> From: Martyn Welch <martyn.welch@collabora.com> >>>> >>>> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in >>>> the MCU domain. This core is typically used for safety applications in a >>>> stand alone mode. However, some application (non safety related) may >>>> want to use the M4F core as a generic remote processor with IPC to the >>>> host processor. The M4F core has internal IRAM and DRAM memories and are >>>> exposed to the system bus for code and data loading. >>>> >>>> A remote processor driver is added to support this subsystem, including >>>> being able to load and boot the M4F core. Loading includes to M4F >>>> internal memories and predefined external code/data memories. The >>>> carve outs for external contiguous memory is defined in the M4F device >>>> node and should match with the external memory declarations in the M4F >>>> image binary. The M4F subsystem has two resets. One reset is for the >>>> entire subsystem i.e including the internal memories and the other, a >>>> local reset is only for the M4F processing core. When loading the image, >>>> the driver first releases the subsystem reset, loads the firmware image >>>> and then releases the local reset to let the M4F processing core run. >>>> >>>> Signed-off-by: Martyn Welch <martyn.welch@collabora.com> >>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com> >>>> Signed-off-by: Andrew Davis <afd@ti.com> >>>> --- >>>> drivers/remoteproc/Kconfig | 13 + >>>> drivers/remoteproc/Makefile | 1 + >>>> drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++++++++++++++++++++++ >>>> 3 files changed, 799 insertions(+) >>>> create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c >>>> >>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig >>>> index 48845dc8fa852..1a7c0330c91a9 100644 >>>> --- a/drivers/remoteproc/Kconfig >>>> +++ b/drivers/remoteproc/Kconfig >>>> @@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC >>>> It's safe to say N here if you're not interested in utilizing >>>> the DSP slave processors. >>>> >>>> +config TI_K3_M4_REMOTEPROC >>>> + tristate "TI K3 M4 remoteproc support" >>>> + depends on ARCH_K3 || COMPILE_TEST >>>> + select MAILBOX >>>> + select OMAP2PLUS_MBOX >>>> + help >>>> + Say m here to support TI's M4 remote processor subsystems >>>> + on various TI K3 family of SoCs through the remote processor >>>> + framework. >>>> + >>>> + It's safe to say N here if you're not interested in utilizing >>>> + a remote processor. >>>> + >>>> config TI_K3_R5_REMOTEPROC >>>> tristate "TI K3 R5 remoteproc support" >>>> depends on ARCH_K3 >>>> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile >>>> index 91314a9b43cef..5ff4e2fee4abd 100644 >>>> --- a/drivers/remoteproc/Makefile >>>> +++ b/drivers/remoteproc/Makefile >>>> @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o >>>> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o >>>> obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o >>>> obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o >>>> +obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o >>>> obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o >>>> obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o >>>> diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c b/drivers/remoteproc/ti_k3_m4_remoteproc.c >>>> new file mode 100644 >>>> index 0000000000000..0030e509f6b5d >>>> --- /dev/null >>>> +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c >>>> @@ -0,0 +1,785 @@ >>>> +// SPDX-License-Identifier: GPL-2.0-only >>>> +/* >>>> + * TI K3 Cortex-M4 Remote Processor(s) driver >>>> + * >>>> + * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/ >>>> + * Hari Nagalla <hnagalla@ti.com> >>>> + */ >>>> + >>>> +#include <linux/io.h> >>>> +#include <linux/mailbox_client.h> >>>> +#include <linux/module.h> >>>> +#include <linux/of_address.h> >>>> +#include <linux/of_reserved_mem.h> >>>> +#include <linux/platform_device.h> >>>> +#include <linux/remoteproc.h> >>>> +#include <linux/reset.h> >>>> +#include <linux/slab.h> >>>> + >>>> +#include "omap_remoteproc.h" >>>> +#include "remoteproc_internal.h" >>>> +#include "ti_sci_proc.h" >>>> + >>>> +/** >>>> + * struct k3_m4_rproc_mem - internal memory structure >>>> + * @cpu_addr: MPU virtual address of the memory region >>>> + * @bus_addr: Bus address used to access the memory region >>>> + * @dev_addr: Device address of the memory region from remote processor view >>>> + * @size: Size of the memory region >>>> + */ >>>> +struct k3_m4_rproc_mem { >>>> + void __iomem *cpu_addr; >>>> + phys_addr_t bus_addr; >>>> + u32 dev_addr; >>>> + size_t size; >>>> +}; >>>> + >>>> +/** >>>> + * struct k3_m4_rproc_mem_data - memory definitions for a remote processor >>>> + * @name: name for this memory entry >>>> + * @dev_addr: device address for the memory entry >>>> + */ >>>> +struct k3_m4_rproc_mem_data { >>>> + const char *name; >>>> + const u32 dev_addr; >>>> +}; >>>> + >>>> +/** >>>> + * struct k3_m4_rproc_dev_data - device data structure for a remote processor >>>> + * @mems: pointer to memory definitions for a remote processor >>>> + * @num_mems: number of memory regions in @mems >>>> + * @uses_lreset: flag to denote the need for local reset management >>>> + */ >>>> +struct k3_m4_rproc_dev_data { >>>> + const struct k3_m4_rproc_mem_data *mems; >>>> + u32 num_mems; >>>> + bool uses_lreset; >>>> +}; >>>> + >>>> +/** >>>> + * struct k3_m4_rproc - k3 remote processor driver structure >>>> + * @dev: cached device pointer >>>> + * @rproc: remoteproc device handle >>>> + * @mem: internal memory regions data >>>> + * @num_mems: number of internal memory regions >>>> + * @rmem: reserved memory regions data >>>> + * @num_rmems: number of reserved memory regions >>>> + * @reset: reset control handle >>>> + * @data: pointer to device data >>>> + * @tsp: TI-SCI processor control handle >>>> + * @ti_sci: TI-SCI handle >>>> + * @ti_sci_id: TI-SCI device identifier >>>> + * @mbox: mailbox channel handle >>>> + * @client: mailbox client to request the mailbox channel >>>> + */ >>>> +struct k3_m4_rproc { >>>> + struct device *dev; >>>> + struct rproc *rproc; >>>> + struct k3_m4_rproc_mem *mem; >>>> + int num_mems; >>>> + struct k3_m4_rproc_mem *rmem; >>>> + int num_rmems; >>>> + struct reset_control *reset; >>>> + const struct k3_m4_rproc_dev_data *data; >>>> + struct ti_sci_proc *tsp; >>>> + const struct ti_sci_handle *ti_sci; >>>> + u32 ti_sci_id; >>>> + struct mbox_chan *mbox; >>>> + struct mbox_client client; >>>> +}; >>>> + >>>> +/** >>>> + * k3_m4_rproc_mbox_callback() - inbound mailbox message handler >>>> + * @client: mailbox client pointer used for requesting the mailbox channel >>>> + * @data: mailbox payload >>>> + * >>>> + * This handler is invoked by the K3 mailbox driver whenever a mailbox >>>> + * message is received. Usually, the mailbox payload simply contains >>>> + * the index of the virtqueue that is kicked by the remote processor, >>>> + * and we let remoteproc core handle it. >>>> + * >>>> + * In addition to virtqueue indices, we also have some out-of-band values >>>> + * that indicate different events. Those values are deliberately very >>>> + * large so they don't coincide with virtqueue indices. >>>> + */ >>>> +static void k3_m4_rproc_mbox_callback(struct mbox_client *client, void *data) >>>> +{ >>>> + struct k3_m4_rproc *kproc = container_of(client, struct k3_m4_rproc, >>>> + client); >>>> + struct device *dev = kproc->rproc->dev.parent; >>>> + const char *name = kproc->rproc->name; >>>> + u32 msg = (u32)(uintptr_t)(data); >>>> + >>>> + dev_dbg(dev, "mbox msg: 0x%x\n", msg); >>>> + >>>> + switch (msg) { >>>> + case RP_MBOX_CRASH: >>>> + /* >>>> + * remoteproc detected an exception, but error recovery is not >>>> + * supported. So, just log this for now >>>> + */ >>>> + dev_err(dev, "K3 rproc %s crashed\n", name); >>>> + break; >>>> + case RP_MBOX_ECHO_REPLY: >>>> + dev_info(dev, "received echo reply from %s\n", name); >>>> + break; >>>> + default: >>>> + /* silently handle all other valid messages */ >>>> + if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG) >>>> + return; >>>> + if (msg > kproc->rproc->max_notifyid) { >>>> + dev_dbg(dev, "dropping unknown message 0x%x", msg); >>>> + return; >>>> + } >>>> + /* msg contains the index of the triggered vring */ >>>> + if (rproc_vq_interrupt(kproc->rproc, msg) == IRQ_NONE) >>>> + dev_dbg(dev, "no message was found in vqid %d\n", msg); >>>> + } >>>> +} >>>> + >>>> +/* >>>> + * Kick the remote processor to notify about pending unprocessed messages. >>>> + * The vqid usage is not used and is inconsequential, as the kick is performed >>>> + * through a simulated GPIO (a bit in an IPC interrupt-triggering register), >>>> + * the remote processor is expected to process both its Tx and Rx virtqueues. >>>> + */ >>>> +static void k3_m4_rproc_kick(struct rproc *rproc, int vqid) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + struct device *dev = rproc->dev.parent; >>>> + u32 msg = (u32)vqid; >>>> + int ret; >>>> + >>>> + /* send the index of the triggered virtqueue in the mailbox payload */ >>>> + ret = mbox_send_message(kproc->mbox, (void *)(uintptr_t)msg); >>> >>> I remember discussing this but can't recall the outcome. Still, I don't see >>> why (uintptr_t) is needed here. >>> >> >> Was discussed here: https://lkml.org/lkml/2024/3/28/974 >> >> Re-quoting my response from last time: >> >>> Doing that in one step (u32 -> void*) causes a warning when void* is 64bit >>> (cast from int to pointer of different size). >> > > I remember now - please add a comment that supports using the syntax. > That way we avoid receiving patches and once again having to review > this. >
Sure, will add a comment.
>>>> + if (ret < 0) >>>> + dev_err(dev, "failed to send mailbox message, status = %d\n", >>>> + ret); >>>> +} >>>> + >>>> +/* Put the remote processor into reset */ >>>> +static int k3_m4_rproc_reset(struct k3_m4_rproc *kproc) >>>> +{ >>>> + struct device *dev = kproc->dev; >>>> + int ret; >>>> + >>>> + ret = reset_control_assert(kproc->reset); >>>> + if (ret) { >>>> + dev_err(dev, "local-reset assert failed, ret = %d\n", ret); >>>> + return ret; >>>> + } >>>> + >>>> + if (kproc->data->uses_lreset) >>>> + return ret; >>>> + >>>> + ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci, >>>> + kproc->ti_sci_id); >>>> + if (ret) { >>>> + dev_err(dev, "module-reset assert failed, ret = %d\n", ret); >>>> + if (reset_control_deassert(kproc->reset)) >>>> + dev_warn(dev, "local-reset deassert back failed\n"); >>>> + } >>>> + >>>> + return ret; >>>> +} >>>> + >>>> +/* Release the remote processor from reset */ >>>> +static int k3_m4_rproc_release(struct k3_m4_rproc *kproc) >>>> +{ >>>> + struct device *dev = kproc->dev; >>>> + int ret; >>>> + >>>> + if (kproc->data->uses_lreset) >>>> + goto lreset; >>>> + >>>> + ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci, >>>> + kproc->ti_sci_id); >>>> + if (ret) { >>>> + dev_err(dev, "module-reset deassert failed, ret = %d\n", ret); >>>> + return ret; >>>> + } >>>> + >>>> +lreset: >>>> + ret = reset_control_deassert(kproc->reset); >>>> + if (ret) { >>>> + dev_err(dev, "local-reset deassert failed, ret = %d\n", ret); >>>> + if (kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci, >>>> + kproc->ti_sci_id)) >>> >>> This is done unconditionally, even when dev_ops.get_device() above hasn't been >>> called. >>> >> >> Will rework to fix that, seems this is also a problem for ti_k3_dsp_remoteproc.c >> from which this function was based. Will fix that too when we factor out these >> common functions. >> >>>> + dev_warn(dev, "module-reset assert back failed\n"); >>>> + } >>>> + >>>> + return ret; >>>> +} >>>> + >>>> +static int k3_m4_rproc_request_mbox(struct rproc *rproc) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + struct mbox_client *client = &kproc->client; >>>> + struct device *dev = kproc->dev; >>>> + int ret; >>>> + >>>> + client->dev = dev; >>>> + client->tx_done = NULL; >>>> + client->rx_callback = k3_m4_rproc_mbox_callback; >>>> + client->tx_block = false; >>>> + client->knows_txdone = false; >>>> + >>>> + kproc->mbox = mbox_request_channel(client, 0); >>>> + if (IS_ERR(kproc->mbox)) { >>>> + ret = -EBUSY; >>>> + dev_err(dev, "mbox_request_channel failed: %ld\n", >>>> + PTR_ERR(kproc->mbox)); >>>> + return ret; >>>> + } >>>> + >>>> + /* >>>> + * Ping the remote processor, this is only for sanity-sake for now; >>>> + * there is no functional effect whatsoever. >>>> + * >>>> + * Note that the reply will _not_ arrive immediately: this message >>>> + * will wait in the mailbox fifo until the remote processor is booted. >>>> + */ >>>> + ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST); >>>> + if (ret < 0) { >>>> + dev_err(dev, "mbox_send_message failed: %d\n", ret); >>>> + mbox_free_channel(kproc->mbox); >>>> + return ret; >>>> + } >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +/* >>>> + * The M4 cores have a local reset that affects only the CPU, and a >>>> + * generic module reset that powers on the device and allows the internal >>>> + * memories to be accessed while the local reset is asserted. This function is >>>> + * used to release the global reset on remote cores to allow loading into the >>>> + * internal RAMs. The .prepare() ops is invoked by remoteproc core before any >>>> + * firmware loading, and is followed by the .start() ops after loading to >>>> + * actually let the remote cores to run. This callback is invoked only in >>>> + * remoteproc mode. >>>> + */ >>>> +static int k3_m4_rproc_prepare(struct rproc *rproc) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + struct device *dev = kproc->dev; >>>> + int ret; >>>> + >>>> + ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci, >>>> + kproc->ti_sci_id); >>>> + if (ret) >>>> + dev_err(dev, "module-reset deassert failed, cannot enable internal RAM loading, ret = %d\n", >>>> + ret); >>>> + >>>> + return ret; >>>> +} >>>> + >>>> +/* >>>> + * This function implements the .unprepare() ops and performs the complimentary >>>> + * operations to that of the .prepare() ops. The function is used to assert the >>>> + * global reset on applicable cores. This completes the second portion of >>>> + * powering down the remote core. The cores themselves are only halted in the >>>> + * .stop() callback through the local reset, and the .unprepare() ops is invoked >>>> + * by the remoteproc core after the remoteproc is stopped to balance the global >>>> + * reset. This callback is invoked only in remoteproc mode. >>>> + */ >>>> +static int k3_m4_rproc_unprepare(struct rproc *rproc) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + struct device *dev = kproc->dev; >>>> + int ret; >>>> + >>>> + ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci, >>>> + kproc->ti_sci_id); >>>> + if (ret) >>>> + dev_err(dev, "module-reset assert failed, ret = %d\n", ret); >>>> + >>>> + return ret; >>>> +} >>>> + >>>> +/* >>>> + * This function implements the .get_loaded_rsc_table() callback and is used >>>> + * to provide the resource table for a booted remote processor in IPC-only >>>> + * mode. The remote processor firmwares follow a design-by-contract approach >>>> + * and are expected to have the resource table at the base of the DDR region >>>> + * reserved for firmware usage. This provides flexibility for the remote >>>> + * processor to be booted by different bootloaders that may or may not have the >>>> + * ability to publish the resource table address and size through a DT >>>> + * property. >>>> + */ >>>> +static struct resource_table *k3_m4_get_loaded_rsc_table(struct rproc *rproc, >>>> + size_t *rsc_table_sz) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + struct device *dev = kproc->dev; >>>> + >>>> + if (!kproc->rmem[0].cpu_addr) { >>>> + dev_err(dev, "memory-region #1 does not exist, loaded rsc table can't be found"); >>>> + return ERR_PTR(-ENOMEM); >>>> + } >>>> + >>>> + /* >>>> + * NOTE: The resource table size is currently hard-coded to a maximum >>>> + * of 256 bytes. The most common resource table usage for K3 firmwares >>>> + * is to only have the vdev resource entry and an optional trace entry. >>>> + * The exact size could be computed based on resource table address, but >>>> + * the hard-coded value suffices to support the IPC-only mode. >>>> + */ >>>> + *rsc_table_sz = 256; >>>> + return (__force struct resource_table *)kproc->rmem[0].cpu_addr; >>>> +} >>>> + >>>> +/* >>>> + * Custom function to translate a remote processor device address (internal >>>> + * RAMs only) to a kernel virtual address. The remote processors can access >>>> + * their RAMs at either an internal address visible only from a remote >>>> + * processor, or at the SoC-level bus address. Both these addresses need to be >>>> + * looked through for translation. The translated addresses can be used either >>>> + * by the remoteproc core for loading (when using kernel remoteproc loader), or >>>> + * by any rpmsg bus drivers. >>>> + */ >>>> +static void *k3_m4_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + void __iomem *va = NULL; >>>> + phys_addr_t bus_addr; >>>> + u32 dev_addr, offset; >>>> + size_t size; >>>> + int i; >>>> + >>>> + if (len == 0) >>>> + return NULL; >>>> + >>>> + for (i = 0; i < kproc->num_mems; i++) { >>>> + bus_addr = kproc->mem[i].bus_addr; >>>> + dev_addr = kproc->mem[i].dev_addr; >>>> + size = kproc->mem[i].size; >>>> + >>>> + /* handle M4-view addresses */ >>>> + if (da >= dev_addr && ((da + len) <= (dev_addr + size))) { >>>> + offset = da - dev_addr; >>>> + va = kproc->mem[i].cpu_addr + offset; >>>> + return (__force void *)va; >>>> + } >>>> + >>>> + /* handle SoC-view addresses */ >>>> + if (da >= bus_addr && ((da + len) <= (bus_addr + size))) { >>>> + offset = da - bus_addr; >>>> + va = kproc->mem[i].cpu_addr + offset; >>>> + return (__force void *)va; >>>> + } >>>> + } >>>> + >>>> + /* handle static DDR reserved memory regions */ >>>> + for (i = 0; i < kproc->num_rmems; i++) { >>>> + dev_addr = kproc->rmem[i].dev_addr; >>>> + size = kproc->rmem[i].size; >>>> + >>>> + if (da >= dev_addr && ((da + len) <= (dev_addr + size))) { >>>> + offset = da - dev_addr; >>>> + va = kproc->rmem[i].cpu_addr + offset; >>>> + return (__force void *)va; >>>> + } >>>> + } >>>> + >>>> + return NULL; >>>> +} >>>> + >>>> +static int k3_m4_rproc_of_get_memories(struct platform_device *pdev, >>>> + struct k3_m4_rproc *kproc) >>>> +{ >>>> + const struct k3_m4_rproc_dev_data *data = kproc->data; >>>> + struct device *dev = &pdev->dev; >>>> + struct resource *res; >>>> + int num_mems = 0; >>>> + int i; >>>> + >>>> + num_mems = kproc->data->num_mems; >>>> + kproc->mem = devm_kcalloc(kproc->dev, num_mems, >>>> + sizeof(*kproc->mem), GFP_KERNEL); >>>> + if (!kproc->mem) >>>> + return -ENOMEM; >>>> + >>>> + for (i = 0; i < num_mems; i++) { >>>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, >>>> + data->mems[i].name); >>>> + if (!res) { >>>> + dev_err(dev, "found no memory resource for %s\n", >>>> + data->mems[i].name); >>>> + return -EINVAL; >>>> + } >>>> + if (!devm_request_mem_region(dev, res->start, >>>> + resource_size(res), >>>> + dev_name(dev))) { >>>> + dev_err(dev, "could not request %s region for resource\n", >>>> + data->mems[i].name); >>>> + return -EBUSY; >>>> + } >>>> + >>>> + kproc->mem[i].cpu_addr = devm_ioremap_wc(dev, res->start, >>>> + resource_size(res)); >>>> + if (!kproc->mem[i].cpu_addr) { >>>> + dev_err(dev, "failed to map %s memory\n", >>>> + data->mems[i].name); >>>> + return -ENOMEM; >>>> + } >>>> + kproc->mem[i].bus_addr = res->start; >>>> + kproc->mem[i].dev_addr = data->mems[i].dev_addr; >>>> + kproc->mem[i].size = resource_size(res); >>>> + >>>> + dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %pK da 0x%x\n", >>>> + data->mems[i].name, &kproc->mem[i].bus_addr, >>> >>> I'm pretty sure you are intrested in kproc->mem[i].bus_addr rather than >>> &kproc->mem[i].bus_addr. >>> >> >> I think this is correct as it is, the %pa format takes a "reference" to what >> we are interested in, so we need to pass the address of the address :) >> > > You are correct. > >> https://www.kernel.org/doc/Documentation/printk-formats.txt >> >>>> + kproc->mem[i].size, kproc->mem[i].cpu_addr, >>>> + kproc->mem[i].dev_addr); >>>> + } >>>> + kproc->num_mems = num_mems; >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +static void k3_m4_rproc_dev_mem_release(void *data) >>>> +{ >>>> + struct device *dev = data; >>>> + >>>> + of_reserved_mem_device_release(dev); >>>> +} >>>> + >>>> +static int k3_m4_reserved_mem_init(struct k3_m4_rproc *kproc) >>>> +{ >>>> + struct device *dev = kproc->dev; >>>> + struct device_node *np = dev->of_node; >>>> + struct device_node *rmem_np; >>>> + struct reserved_mem *rmem; >>>> + int num_rmems; >>>> + int ret, i; >>>> + >>>> + num_rmems = of_property_count_elems_of_size(np, "memory-region", >>>> + sizeof(phandle)); >>>> + if (num_rmems < 0) { >>>> + dev_err(dev, "device does not reserved memory regions (%pe)\n", >>>> + ERR_PTR(num_rmems)); >>> >>> Why use %pe and ERR_PTR() when function of_property_count_elems_of_size() >>> returns a simple error code? >>> >> >> Done to match the same in ti_k3_dsp_remoteproc.c but I see no good reason >> for it, will fix. >> >>>> + return -EINVAL; >>>> + } >>>> + if (num_rmems < 2) { >>>> + dev_err(dev, "device needs at least two memory regions to be defined, num = %d\n", >>>> + num_rmems); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + /* use reserved memory region 0 for vring DMA allocations */ >>>> + ret = of_reserved_mem_device_init_by_idx(dev, np, 0); >>>> + if (ret) { >>>> + dev_err(dev, "device cannot initialize DMA pool (%pe)\n", >>>> + ERR_PTR(ret)); >>> >>> Same >>> >>>> + return ret; >>>> + } >>>> + ret = devm_add_action_or_reset(dev, k3_m4_rproc_dev_mem_release, dev); >>>> + if (ret) >>>> + return ret; >>>> + >>>> + num_rmems--; >>>> + kproc->rmem = devm_kcalloc(dev, num_rmems, sizeof(*kproc->rmem), GFP_KERNEL); >>>> + if (!kproc->rmem) >>>> + return -ENOMEM; >>>> + >>>> + /* use remaining reserved memory regions for static carveouts */ >>>> + for (i = 0; i < num_rmems; i++) { >>>> + rmem_np = of_parse_phandle(np, "memory-region", i + 1); >>>> + if (!rmem_np) >>>> + return -EINVAL; >>>> + >>>> + rmem = of_reserved_mem_lookup(rmem_np); >>>> + if (!rmem) { >>>> + of_node_put(rmem_np); >>>> + return -EINVAL; >>>> + } >>>> + of_node_put(rmem_np); >>>> + >>>> + kproc->rmem[i].bus_addr = rmem->base; >>>> + /* 64-bit address regions currently not supported */ >>>> + kproc->rmem[i].dev_addr = (u32)rmem->base; >>>> + kproc->rmem[i].size = rmem->size; >>>> + kproc->rmem[i].cpu_addr = devm_ioremap_wc(dev, rmem->base, rmem->size); >>>> + if (!kproc->rmem[i].cpu_addr) { >>>> + dev_err(dev, "failed to map reserved memory#%d at %pa of size %pa\n", >>>> + i + 1, &rmem->base, &rmem->size); >>>> + return -ENOMEM; >>>> + } >>>> + >>>> + dev_dbg(dev, "reserved memory%d: bus addr %pa size 0x%zx va %pK da 0x%x\n", >>>> + i + 1, &kproc->rmem[i].bus_addr, >>>> + kproc->rmem[i].size, kproc->rmem[i].cpu_addr, >>>> + kproc->rmem[i].dev_addr); >>>> + } >>>> + kproc->num_rmems = num_rmems; >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +static struct ti_sci_proc *k3_m4_rproc_of_get_tsp(struct device *dev, >>>> + const struct ti_sci_handle *sci) >>>> +{ >>>> + struct ti_sci_proc *tsp; >>>> + u32 temp[2]; >>>> + int ret; >>>> + >>>> + ret = of_property_read_u32_array(dev->of_node, "ti,sci-proc-ids", >>>> + temp, 2); >>>> + if (ret < 0) >>>> + return ERR_PTR(ret); >>>> + >>>> + tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL); >>>> + if (!tsp) >>>> + return ERR_PTR(-ENOMEM); >>>> + >>>> + tsp->dev = dev; >>>> + tsp->sci = sci; >>>> + tsp->ops = &sci->ops.proc_ops; >>>> + tsp->proc_id = temp[0]; >>>> + tsp->host_id = temp[1]; >>>> + >>>> + return tsp; >>>> +} >>>> + >>>> +static void k3_m4_release_tsp(void *data) >>>> +{ >>>> + struct ti_sci_proc *tsp = data; >>>> + >>>> + ti_sci_proc_release(tsp); >>>> +} >>>> + >>>> +/* >>>> + * Power up the M4F remote processor. >>>> + * >>>> + * This function will be invoked only after the firmware for this rproc >>>> + * was loaded, parsed successfully, and all of its resource requirements >>>> + * were met. This callback is invoked only in remoteproc mode. >>>> + */ >>>> +static int k3_m4_rproc_start(struct rproc *rproc) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + int ret; >>>> + >>>> + ret = k3_m4_rproc_request_mbox(rproc); >>>> + if (ret) >>>> + return ret; >>>> + >>>> + ret = k3_m4_rproc_release(kproc); >>>> + if (ret) >>>> + goto put_mbox; >>>> + >>>> + return 0; >>>> + >>>> +put_mbox: >>>> + mbox_free_channel(kproc->mbox); >>>> + return ret; >>>> +} >>>> + >>>> +/* >>>> + * Stop the M4 remote processor. >>>> + * >>>> + * This function puts the M4 processor into reset, and finishes processing >>>> + * of any pending messages. This callback is invoked only in remoteproc mode. >>>> + */ >>>> +static int k3_m4_rproc_stop(struct rproc *rproc) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + >>>> + mbox_free_channel(kproc->mbox); >>>> + >>>> + k3_m4_rproc_reset(kproc); >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +/* >>>> + * Attach to a running M4 remote processor (IPC-only mode) >>>> + * >>>> + * This rproc attach callback only needs to request the mailbox, the remote >>>> + * processor is already booted, so there is no need to issue any TI-SCI >>>> + * commands to boot the M4 core. This callback is used only in IPC-only mode. >>>> + */ >>>> +static int k3_m4_rproc_attach(struct rproc *rproc) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + struct device *dev = kproc->dev; >>>> + int ret; >>>> + >>>> + ret = k3_m4_rproc_request_mbox(rproc); >>>> + if (ret) >>>> + return ret; >>>> + >>>> + dev_info(dev, "M4 initialized in IPC-only mode\n"); >>>> + return 0; >>>> +} >>>> + >>>> +/* >>>> + * Detach from a running M4 remote processor (IPC-only mode) >>>> + * >>>> + * This rproc detach callback performs the opposite operation to attach callback >>>> + * and only needs to release the mailbox, the M4 core is not stopped and will >>>> + * be left to continue to run its booted firmware. This callback is invoked only in >>>> + * IPC-only mode. >>>> + */ >>>> +static int k3_m4_rproc_detach(struct rproc *rproc) >>>> +{ >>>> + struct k3_m4_rproc *kproc = rproc->priv; >>>> + struct device *dev = kproc->dev; >>>> + >>>> + mbox_free_channel(kproc->mbox); >>>> + dev_info(dev, "M4 deinitialized in IPC-only mode\n"); >>>> + return 0; >>>> +} >>>> + >>>> +static const struct rproc_ops k3_m4_rproc_ops = { >>>> + .start = k3_m4_rproc_start, >>>> + .stop = k3_m4_rproc_stop, >>>> + .attach = k3_m4_rproc_attach, >>>> + .detach = k3_m4_rproc_detach, >>>> + .kick = k3_m4_rproc_kick, >>>> + .da_to_va = k3_m4_rproc_da_to_va, >>>> + .get_loaded_rsc_table = k3_m4_get_loaded_rsc_table, >>>> +}; >>>> + >>>> +static int k3_m4_rproc_probe(struct platform_device *pdev) >>>> +{ >>>> + struct device *dev = &pdev->dev; >>>> + struct device_node *np = dev->of_node; >>>> + const struct k3_m4_rproc_dev_data *data; >>>> + struct k3_m4_rproc *kproc; >>>> + struct rproc *rproc; >>>> + const char *fw_name; >>>> + bool r_state = false; >>>> + bool p_state = false; >>>> + int ret = 0; >>>> + >>>> + data = device_get_match_data(dev); >>>> + if (!data) >>>> + return -ENODEV; >>>> + >>>> + ret = rproc_of_parse_firmware(dev, 0, &fw_name); >>>> + if (ret) >>>> + return dev_err_probe(dev, ret, "failed to parse firmware-name property\n"); >>>> + >>>> + rproc = devm_rproc_alloc(dev, dev_name(dev), &k3_m4_rproc_ops, fw_name, >>>> + sizeof(*kproc)); >>>> + if (!rproc) >>>> + return -ENOMEM; >>>> + >>>> + rproc->has_iommu = false; >>>> + rproc->recovery_disabled = true; >>>> + if (data->uses_lreset) { >>>> + rproc->ops->prepare = k3_m4_rproc_prepare; >>>> + rproc->ops->unprepare = k3_m4_rproc_unprepare; >>>> + } >>>> + kproc = rproc->priv; >>>> + kproc->rproc = rproc; >>>> + kproc->dev = dev; >>>> + kproc->data = data; >>>> + >>>> + kproc->ti_sci = devm_ti_sci_get_by_phandle(dev, "ti,sci"); >>>> + if (IS_ERR(kproc->ti_sci)) >>>> + return dev_err_probe(dev, PTR_ERR(kproc->ti_sci), >>>> + "failed to get ti-sci handle\n"); >>>> + >>>> + ret = of_property_read_u32(np, "ti,sci-dev-id", &kproc->ti_sci_id); >>>> + if (ret) >>>> + return dev_err_probe(dev, ret, "missing 'ti,sci-dev-id' property\n"); >>>> + >>>> + kproc->reset = devm_reset_control_get_exclusive(dev, NULL); >>>> + if (IS_ERR(kproc->reset)) >>>> + return dev_err_probe(dev, PTR_ERR(kproc->reset), "failed to get reset\n"); >>>> + >>>> + kproc->tsp = k3_m4_rproc_of_get_tsp(dev, kproc->ti_sci); >>>> + if (IS_ERR(kproc->tsp)) >>>> + return dev_err_probe(dev, PTR_ERR(kproc->tsp), >>>> + "failed to construct ti-sci proc control\n"); >>>> + >>>> + ret = ti_sci_proc_request(kproc->tsp); >>>> + if (ret < 0) >>>> + return dev_err_probe(dev, ret, "ti_sci_proc_request failed\n"); >>>> + ret = devm_add_action_or_reset(dev, k3_m4_release_tsp, kproc->tsp); >>>> + if (ret) >>>> + return ret; >>>> + >>>> + ret = k3_m4_rproc_of_get_memories(pdev, kproc); >>>> + if (ret) >>>> + return ret; >>>> + >>>> + ret = k3_m4_reserved_mem_init(kproc); >>>> + if (ret) >>>> + return dev_err_probe(dev, ret, "reserved memory init failed\n"); >>>> + >>>> + ret = kproc->ti_sci->ops.dev_ops.is_on(kproc->ti_sci, kproc->ti_sci_id, >>>> + &r_state, &p_state); >>>> + if (ret) >>>> + return dev_err_probe(dev, ret, >>>> + "failed to get initial state, mode cannot be determined\n"); >>>> + >>>> + /* configure devices for either remoteproc or IPC-only mode */ >>>> + if (p_state) { >>>> + dev_info(dev, "configured M4 for IPC-only mode\n"); >>>> + rproc->state = RPROC_DETACHED; >>>> + /* override rproc ops with only required IPC-only mode ops */ >>>> + rproc->ops->prepare = NULL; >>>> + rproc->ops->unprepare = NULL; >>>> + rproc->ops->start = NULL; >>>> + rproc->ops->stop = NULL; >>>> + rproc->ops->attach = k3_m4_rproc_attach; >>>> + rproc->ops->detach = k3_m4_rproc_detach; >>>> + rproc->ops->get_loaded_rsc_table = k3_m4_get_loaded_rsc_table; >>>> + } else { >>>> + dev_info(dev, "configured M4 for remoteproc mode\n"); >>>> + /* >>>> + * ensure the M4 local reset is asserted to ensure the core >>>> + * doesn't execute bogus code in .prepare() when the module >>>> + * reset is released. >>>> + */ >>>> + if (data->uses_lreset) { >>>> + ret = reset_control_status(kproc->reset); >>>> + if (ret < 0) { >>>> + return dev_err_probe(dev, ret, "failed to get reset status\n"); >>>> + } else if (ret == 0) { >>>> + dev_warn(dev, "local reset is deasserted for device\n"); >>>> + k3_m4_rproc_reset(kproc); >>>> + } >>>> + } >>>> + } >>>> + >>>> + ret = devm_rproc_add(dev, rproc); >>>> + if (ret) >>>> + return dev_err_probe(dev, ret, >>>> + "failed to add register device with remoteproc core\n"); >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +static const struct k3_m4_rproc_mem_data am64_m4_mems[] = { >>>> + { .name = "iram", .dev_addr = 0x0 }, >>>> + { .name = "dram", .dev_addr = 0x30000 }, >>>> +}; >>>> + >>>> +static const struct k3_m4_rproc_dev_data am64_m4_data = { >>>> + .mems = am64_m4_mems, >>>> + .num_mems = ARRAY_SIZE(am64_m4_mems), >>>> + .uses_lreset = true, >>> >>> If this is the case, why carrying k3_m4_rproc_dev_data::uses_lreset and all the >>> code around it? >>> >> >> It was to keep most of these functions consistent with k3-r5 and k3-dsp drivers >> which do optionally have this local reset. For now I'll just remove it from >> here. >> >> Thanks, >> Andrew >> >>> I am done reviewing this set. >>> >>> Regards, >>> Mathieu >>> >>>> +}; >>>> + >>>> +static const struct of_device_id k3_m4_of_match[] = { >>>> + { .compatible = "ti,am64-m4fss", .data = &am64_m4_data, }, >>>> + { /* sentinel */ }, >>>> +}; >>>> +MODULE_DEVICE_TABLE(of, k3_m4_of_match); >>>> + >>>> +static struct platform_driver k3_m4_rproc_driver = { >>>> + .probe = k3_m4_rproc_probe, >>>> + .driver = { >>>> + .name = "k3-m4-rproc", >>>> + .of_match_table = k3_m4_of_match, >>>> + }, >>>> +}; >>>> +module_platform_driver(k3_m4_rproc_driver); >>>> + >>>> +MODULE_AUTHOR("Hari Nagalla <hnagalla@ti.com>"); >>>> +MODULE_DESCRIPTION("TI K3 M4 Remoteproc driver"); >>>> +MODULE_LICENSE("GPL"); >>>> -- >>>> 2.39.2 >>>>
| |