From: Suman Anna <s-anna@ti.com> To: Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Lokesh Vutla <lokeshvutla@ti.com>, <linux-remoteproc@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, Suman Anna <s-anna@ti.com> Subject: [PATCH v5 4/4] remoteproc: k3-r5: Add loading support for on-chip SRAM regions Date: Fri, 2 Oct 2020 18:42:34 -0500 [thread overview] Message-ID: <20201002234234.20704-5-s-anna@ti.com> (raw) In-Reply-To: <20201002234234.20704-1-s-anna@ti.com> The K3 SoCs has various internal on-chip SRAM memories like the SRAM within the MCU domain or the shared MSMC RAM within NavSS that can be used for multiple purposes. One such purpose is to have the R5F cores use a portion of such on-chip SRAM for fast-access data or to directly execute code. Add support to the K3 R5 remoteproc driver to parse and support loading into such memories. The SRAM regions need to be mapped as normal non-cacheable memory to avoid kernel crashes when the remoteproc loader code uses the Arm64 memset library function (the "DC ZVA" instruction throws a alignment fault on device type memory). These SRAM regions are completely optional as not all firmware images require these memories, and any such memory has to be reserved as such in the DTS files. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> --- v5: No changes v4: No changes v3: https://patchwork.kernel.org/patch/11679329/ - No code changes, picked up review tags v2: https://patchwork.kernel.org/patch/11632991/ v1: https://patchwork.kernel.org/patch/11456373/ drivers/remoteproc/ti_k3_r5_remoteproc.c | 79 ++++++++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c index a6b395ab47b6..d9307935441d 100644 --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c @@ -85,7 +85,9 @@ struct k3_r5_cluster { * @dev: cached device pointer * @rproc: rproc handle representing this core * @mem: internal memory regions data + * @sram: on-chip SRAM memory regions data * @num_mems: number of internal memory regions + * @num_sram: number of on-chip SRAM memory regions * @reset: reset control handle * @tsp: TI-SCI processor control handle * @ti_sci: TI-SCI handle @@ -99,7 +101,9 @@ struct k3_r5_core { struct device *dev; struct rproc *rproc; struct k3_r5_mem *mem; + struct k3_r5_mem *sram; int num_mems; + int num_sram; struct reset_control *reset; struct ti_sci_proc *tsp; const struct ti_sci_handle *ti_sci; @@ -587,6 +591,18 @@ static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len) } } + /* handle any SRAM regions using SoC-view addresses */ + for (i = 0; i < core->num_sram; i++) { + dev_addr = core->sram[i].dev_addr; + size = core->sram[i].size; + + if (da >= dev_addr && ((da + len) <= (dev_addr + size))) { + offset = da - dev_addr; + va = core->sram[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; @@ -1027,6 +1043,63 @@ static int k3_r5_core_of_get_internal_memories(struct platform_device *pdev, return 0; } +static int k3_r5_core_of_get_sram_memories(struct platform_device *pdev, + struct k3_r5_core *core) +{ + struct device_node *np = pdev->dev.of_node; + struct device *dev = &pdev->dev; + struct device_node *sram_np; + struct resource res; + int num_sram; + int i, ret; + + num_sram = of_property_count_elems_of_size(np, "sram", sizeof(phandle)); + if (num_sram <= 0) { + dev_dbg(dev, "device does not use reserved on-chip memories, num_sram = %d\n", + num_sram); + return 0; + } + + core->sram = devm_kcalloc(dev, num_sram, sizeof(*core->sram), GFP_KERNEL); + if (!core->sram) + return -ENOMEM; + + for (i = 0; i < num_sram; i++) { + sram_np = of_parse_phandle(np, "sram", i); + if (!sram_np) + return -EINVAL; + + if (!of_device_is_available(sram_np)) { + of_node_put(sram_np); + return -EINVAL; + } + + ret = of_address_to_resource(sram_np, 0, &res); + of_node_put(sram_np); + if (ret) + return -EINVAL; + + core->sram[i].bus_addr = res.start; + core->sram[i].dev_addr = res.start; + core->sram[i].size = resource_size(&res); + core->sram[i].cpu_addr = devm_ioremap_wc(dev, res.start, + resource_size(&res)); + if (!core->sram[i].cpu_addr) { + dev_err(dev, "failed to parse and map sram%d memory at %pad\n", + i, &res.start); + return -ENOMEM; + } + + dev_dbg(dev, "memory sram%d: bus addr %pa size 0x%zx va %pK da 0x%x\n", + i, &core->sram[i].bus_addr, + core->sram[i].size, core->sram[i].cpu_addr, + core->sram[i].dev_addr); + } + core->num_sram = num_sram; + + return 0; +} + static struct ti_sci_proc *k3_r5_core_of_get_tsp(struct device *dev, const struct ti_sci_handle *sci) @@ -1142,6 +1215,12 @@ static int k3_r5_core_of_init(struct platform_device *pdev) goto err; } + ret = k3_r5_core_of_get_sram_memories(pdev, core); + if (ret) { + dev_err(dev, "failed to get sram memories, ret = %d\n", ret); + goto err; + } + ret = ti_sci_proc_request(core->tsp); if (ret < 0) { dev_err(dev, "ti_sci_proc_request failed, ret = %d\n", ret); -- 2.28.0
WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com> To: Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, Mathieu Poirier <mathieu.poirier@linaro.org> Cc: devicetree@vger.kernel.org, Lokesh Vutla <lokeshvutla@ti.com>, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH v5 4/4] remoteproc: k3-r5: Add loading support for on-chip SRAM regions Date: Fri, 2 Oct 2020 18:42:34 -0500 [thread overview] Message-ID: <20201002234234.20704-5-s-anna@ti.com> (raw) In-Reply-To: <20201002234234.20704-1-s-anna@ti.com> The K3 SoCs has various internal on-chip SRAM memories like the SRAM within the MCU domain or the shared MSMC RAM within NavSS that can be used for multiple purposes. One such purpose is to have the R5F cores use a portion of such on-chip SRAM for fast-access data or to directly execute code. Add support to the K3 R5 remoteproc driver to parse and support loading into such memories. The SRAM regions need to be mapped as normal non-cacheable memory to avoid kernel crashes when the remoteproc loader code uses the Arm64 memset library function (the "DC ZVA" instruction throws a alignment fault on device type memory). These SRAM regions are completely optional as not all firmware images require these memories, and any such memory has to be reserved as such in the DTS files. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> --- v5: No changes v4: No changes v3: https://patchwork.kernel.org/patch/11679329/ - No code changes, picked up review tags v2: https://patchwork.kernel.org/patch/11632991/ v1: https://patchwork.kernel.org/patch/11456373/ drivers/remoteproc/ti_k3_r5_remoteproc.c | 79 ++++++++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c index a6b395ab47b6..d9307935441d 100644 --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c @@ -85,7 +85,9 @@ struct k3_r5_cluster { * @dev: cached device pointer * @rproc: rproc handle representing this core * @mem: internal memory regions data + * @sram: on-chip SRAM memory regions data * @num_mems: number of internal memory regions + * @num_sram: number of on-chip SRAM memory regions * @reset: reset control handle * @tsp: TI-SCI processor control handle * @ti_sci: TI-SCI handle @@ -99,7 +101,9 @@ struct k3_r5_core { struct device *dev; struct rproc *rproc; struct k3_r5_mem *mem; + struct k3_r5_mem *sram; int num_mems; + int num_sram; struct reset_control *reset; struct ti_sci_proc *tsp; const struct ti_sci_handle *ti_sci; @@ -587,6 +591,18 @@ static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len) } } + /* handle any SRAM regions using SoC-view addresses */ + for (i = 0; i < core->num_sram; i++) { + dev_addr = core->sram[i].dev_addr; + size = core->sram[i].size; + + if (da >= dev_addr && ((da + len) <= (dev_addr + size))) { + offset = da - dev_addr; + va = core->sram[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; @@ -1027,6 +1043,63 @@ static int k3_r5_core_of_get_internal_memories(struct platform_device *pdev, return 0; } +static int k3_r5_core_of_get_sram_memories(struct platform_device *pdev, + struct k3_r5_core *core) +{ + struct device_node *np = pdev->dev.of_node; + struct device *dev = &pdev->dev; + struct device_node *sram_np; + struct resource res; + int num_sram; + int i, ret; + + num_sram = of_property_count_elems_of_size(np, "sram", sizeof(phandle)); + if (num_sram <= 0) { + dev_dbg(dev, "device does not use reserved on-chip memories, num_sram = %d\n", + num_sram); + return 0; + } + + core->sram = devm_kcalloc(dev, num_sram, sizeof(*core->sram), GFP_KERNEL); + if (!core->sram) + return -ENOMEM; + + for (i = 0; i < num_sram; i++) { + sram_np = of_parse_phandle(np, "sram", i); + if (!sram_np) + return -EINVAL; + + if (!of_device_is_available(sram_np)) { + of_node_put(sram_np); + return -EINVAL; + } + + ret = of_address_to_resource(sram_np, 0, &res); + of_node_put(sram_np); + if (ret) + return -EINVAL; + + core->sram[i].bus_addr = res.start; + core->sram[i].dev_addr = res.start; + core->sram[i].size = resource_size(&res); + core->sram[i].cpu_addr = devm_ioremap_wc(dev, res.start, + resource_size(&res)); + if (!core->sram[i].cpu_addr) { + dev_err(dev, "failed to parse and map sram%d memory at %pad\n", + i, &res.start); + return -ENOMEM; + } + + dev_dbg(dev, "memory sram%d: bus addr %pa size 0x%zx va %pK da 0x%x\n", + i, &core->sram[i].bus_addr, + core->sram[i].size, core->sram[i].cpu_addr, + core->sram[i].dev_addr); + } + core->num_sram = num_sram; + + return 0; +} + static struct ti_sci_proc *k3_r5_core_of_get_tsp(struct device *dev, const struct ti_sci_handle *sci) @@ -1142,6 +1215,12 @@ static int k3_r5_core_of_init(struct platform_device *pdev) goto err; } + ret = k3_r5_core_of_get_sram_memories(pdev, core); + if (ret) { + dev_err(dev, "failed to get sram memories, ret = %d\n", ret); + goto err; + } + ret = ti_sci_proc_request(core->tsp); if (ret < 0) { dev_err(dev, "ti_sci_proc_request failed, ret = %d\n", ret); -- 2.28.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-02 23:43 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-02 23:42 [PATCH v5 0/4] TI K3 R5F remoteproc support Suman Anna 2020-10-02 23:42 ` Suman Anna 2020-10-02 23:42 ` [PATCH v5 1/4] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Suman Anna 2020-10-02 23:42 ` Suman Anna 2020-10-02 23:42 ` [PATCH v5 2/4] remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem Suman Anna 2020-10-02 23:42 ` Suman Anna 2020-10-02 23:42 ` [PATCH v5 3/4] remoteproc: k3-r5: Initialize TCM memories for ECC Suman Anna 2020-10-02 23:42 ` Suman Anna 2020-10-02 23:42 ` Suman Anna [this message] 2020-10-02 23:42 ` [PATCH v5 4/4] remoteproc: k3-r5: Add loading support for on-chip SRAM regions Suman Anna 2020-10-14 0:10 ` [PATCH v5 0/4] TI K3 R5F remoteproc support patchwork-bot+linux-remoteproc
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201002234234.20704-5-s-anna@ti.com \ --to=s-anna@ti.com \ --cc=bjorn.andersson@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=lokeshvutla@ti.com \ --cc=mathieu.poirier@linaro.org \ --cc=robh+dt@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.