From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Suman Anna <s-anna@ti.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
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
Subject: Re: [PATCH 7/7] remoteproc/k3-r5: Add loading support for on-chip SRAM regions
Date: Fri, 10 Apr 2020 14:30:06 -0600 [thread overview]
Message-ID: <20200410203006.GA9146@xps15> (raw)
In-Reply-To: <20200324201819.23095-8-s-anna@ti.com>
On Tue, Mar 24, 2020 at 03:18:19PM -0500, Suman Anna wrote:
> 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>
> ---
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 106 ++++++++++++++++++++++-
> 1 file changed, 105 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 8c9b7ae5d8b7..0ae0b66ec9eb 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;
> @@ -585,6 +589,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;
> @@ -1017,6 +1033,77 @@ static int k3_r5_core_of_get_internal_memories(struct platform_device *pdev,
> return ret;
> }
>
> +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 = kcalloc(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) {
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + if (!of_device_is_available(sram_np)) {
> + of_node_put(sram_np);
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + ret = of_address_to_resource(sram_np, 0, &res);
> + of_node_put(sram_np);
> + if (ret) {
> + ret = -EINVAL;
> + goto fail;
> + }
> + 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 = ioremap_wc(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);
> + ret = -ENOMEM;
> + goto fail;
> + }
> +
> + dev_dbg(dev, "memory sram%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
s/"memory sram%d:..."/"memory sram%d:..."
With the above:
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
I am done reviewing this set. Despite the significant amount of material to
process and the comments here and there, I haven't found anything to really
complain about.
Thanks,
Mathieu
> + 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;
> +
> +fail:
> + for (i--; i >= 0; i--) {
> + if (core->sram[i].cpu_addr)
> + iounmap(core->sram[i].cpu_addr);
> + }
> + kfree(core->sram);
> +
> + return ret;
> +}
> +
> static
> struct ti_sci_proc *k3_r5_core_of_get_tsp(struct device *dev,
> const struct ti_sci_handle *sci)
> @@ -1048,7 +1135,7 @@ static int k3_r5_core_of_init(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> struct k3_r5_core *core;
> - int ret, ret1;
> + int ret, ret1, i;
>
> core = devm_kzalloc(dev, sizeof(*core), GFP_KERNEL);
> if (!core)
> @@ -1125,10 +1212,23 @@ static int k3_r5_core_of_init(struct platform_device *pdev)
> goto err_intmem;
> }
>
> + 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_sram;
> + }
> +
> platform_set_drvdata(pdev, core);
>
> return 0;
>
> +err_sram:
> + for (i = 0; i < core->num_mems; i++) {
> + devm_iounmap(dev, core->mem[i].cpu_addr);
> + devm_release_mem_region(dev, core->mem[i].bus_addr,
> + core->mem[i].size);
> + }
> + devm_kfree(dev, core->mem);
> err_intmem:
> ret1 = ti_sci_proc_release(core->tsp);
> if (ret1)
> @@ -1156,6 +1256,10 @@ static int k3_r5_core_of_exit(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> int i, ret;
>
> + for (i = 0; i < core->num_sram; i++)
> + iounmap(core->sram[i].cpu_addr);
> + kfree(core->sram);
> +
> for (i = 0; i < core->num_mems; i++) {
> devm_release_mem_region(dev, core->mem[i].bus_addr,
> core->mem[i].size);
> --
> 2.23.0
>
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Suman Anna <s-anna@ti.com>
Cc: devicetree@vger.kernel.org, Lokesh Vutla <lokeshvutla@ti.com>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 7/7] remoteproc/k3-r5: Add loading support for on-chip SRAM regions
Date: Fri, 10 Apr 2020 14:30:06 -0600 [thread overview]
Message-ID: <20200410203006.GA9146@xps15> (raw)
In-Reply-To: <20200324201819.23095-8-s-anna@ti.com>
On Tue, Mar 24, 2020 at 03:18:19PM -0500, Suman Anna wrote:
> 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>
> ---
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 106 ++++++++++++++++++++++-
> 1 file changed, 105 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 8c9b7ae5d8b7..0ae0b66ec9eb 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;
> @@ -585,6 +589,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;
> @@ -1017,6 +1033,77 @@ static int k3_r5_core_of_get_internal_memories(struct platform_device *pdev,
> return ret;
> }
>
> +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 = kcalloc(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) {
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + if (!of_device_is_available(sram_np)) {
> + of_node_put(sram_np);
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + ret = of_address_to_resource(sram_np, 0, &res);
> + of_node_put(sram_np);
> + if (ret) {
> + ret = -EINVAL;
> + goto fail;
> + }
> + 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 = ioremap_wc(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);
> + ret = -ENOMEM;
> + goto fail;
> + }
> +
> + dev_dbg(dev, "memory sram%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
s/"memory sram%d:..."/"memory sram%d:..."
With the above:
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
I am done reviewing this set. Despite the significant amount of material to
process and the comments here and there, I haven't found anything to really
complain about.
Thanks,
Mathieu
> + 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;
> +
> +fail:
> + for (i--; i >= 0; i--) {
> + if (core->sram[i].cpu_addr)
> + iounmap(core->sram[i].cpu_addr);
> + }
> + kfree(core->sram);
> +
> + return ret;
> +}
> +
> static
> struct ti_sci_proc *k3_r5_core_of_get_tsp(struct device *dev,
> const struct ti_sci_handle *sci)
> @@ -1048,7 +1135,7 @@ static int k3_r5_core_of_init(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> struct k3_r5_core *core;
> - int ret, ret1;
> + int ret, ret1, i;
>
> core = devm_kzalloc(dev, sizeof(*core), GFP_KERNEL);
> if (!core)
> @@ -1125,10 +1212,23 @@ static int k3_r5_core_of_init(struct platform_device *pdev)
> goto err_intmem;
> }
>
> + 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_sram;
> + }
> +
> platform_set_drvdata(pdev, core);
>
> return 0;
>
> +err_sram:
> + for (i = 0; i < core->num_mems; i++) {
> + devm_iounmap(dev, core->mem[i].cpu_addr);
> + devm_release_mem_region(dev, core->mem[i].bus_addr,
> + core->mem[i].size);
> + }
> + devm_kfree(dev, core->mem);
> err_intmem:
> ret1 = ti_sci_proc_release(core->tsp);
> if (ret1)
> @@ -1156,6 +1256,10 @@ static int k3_r5_core_of_exit(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> int i, ret;
>
> + for (i = 0; i < core->num_sram; i++)
> + iounmap(core->sram[i].cpu_addr);
> + kfree(core->sram);
> +
> for (i = 0; i < core->num_mems; i++) {
> devm_release_mem_region(dev, core->mem[i].bus_addr,
> core->mem[i].size);
> --
> 2.23.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-04-10 20:30 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 20:18 [PATCH 0/7] TI K3 R5F remoteproc support Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` [PATCH 1/7] remoteproc: add prepare and unprepare ops Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-26 19:50 ` Bjorn Andersson
2020-03-26 19:51 ` Bjorn Andersson
2020-03-26 19:50 ` Bjorn Andersson
2020-04-06 17:20 ` Mathieu Poirier
2020-04-06 17:20 ` Mathieu Poirier
2020-04-08 23:39 ` Suman Anna
2020-04-08 23:39 ` Suman Anna
2020-04-08 23:39 ` Suman Anna
2020-03-24 20:18 ` [PATCH 2/7] remoteproc: use a local copy for the name field Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-26 5:42 ` Bjorn Andersson
2020-03-26 5:42 ` Bjorn Andersson
2020-03-26 5:42 ` Bjorn Andersson
2020-03-26 14:01 ` Suman Anna
2020-03-26 14:01 ` Suman Anna
2020-03-26 14:01 ` Suman Anna
2020-03-26 19:43 ` Bjorn Andersson
2020-03-26 19:43 ` Bjorn Andersson
2020-03-26 19:43 ` Bjorn Andersson
2020-03-26 20:35 ` Suman Anna
2020-03-26 20:35 ` Suman Anna
2020-03-26 20:35 ` Suman Anna
2020-03-24 20:18 ` [PATCH 3/7] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-26 16:28 ` Rob Herring
2020-03-26 16:28 ` Rob Herring
2020-03-26 16:28 ` Rob Herring
2020-03-26 18:09 ` Suman Anna
2020-03-26 18:09 ` Suman Anna
2020-03-26 18:09 ` Suman Anna
2020-03-26 16:53 ` Rob Herring
2020-03-26 16:53 ` Rob Herring
2020-04-09 0:02 ` Suman Anna
2020-04-09 0:02 ` Suman Anna
2020-04-09 0:02 ` Suman Anna
2020-04-09 0:15 ` Suman Anna
2020-04-09 0:15 ` Suman Anna
2020-04-09 0:15 ` Suman Anna
2020-04-06 19:59 ` Mathieu Poirier
2020-04-06 19:59 ` Mathieu Poirier
2020-04-09 0:12 ` Suman Anna
2020-04-09 0:12 ` Suman Anna
2020-04-09 0:12 ` Suman Anna
2020-03-24 20:18 ` [PATCH 4/7] remoteproc/k3-r5: Add TI-SCI processor control helper functions Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` [PATCH 5/7] remoteproc/k3-r5: Add a remoteproc driver for R5F subsystem Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-04-07 18:08 ` Mathieu Poirier
2020-04-07 18:08 ` Mathieu Poirier
2020-04-09 0:26 ` Suman Anna
2020-04-09 0:26 ` Suman Anna
2020-04-09 0:26 ` Suman Anna
2020-04-08 19:38 ` Mathieu Poirier
2020-04-08 19:38 ` Mathieu Poirier
2020-04-15 22:30 ` Suman Anna
2020-04-15 22:30 ` Suman Anna
2020-04-15 22:30 ` Suman Anna
2020-04-09 21:25 ` Mathieu Poirier
2020-04-09 21:25 ` Mathieu Poirier
2020-04-15 22:44 ` Suman Anna
2020-04-15 22:44 ` Suman Anna
2020-04-15 22:44 ` Suman Anna
2020-04-16 20:11 ` Mathieu Poirier
2020-04-16 20:11 ` Mathieu Poirier
2020-03-24 20:18 ` [PATCH 6/7] remoteproc/k3-r5: Initialize TCM memories for ECC Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-04-09 21:36 ` Mathieu Poirier
2020-04-09 21:36 ` Mathieu Poirier
2020-04-09 22:01 ` Suman Anna
2020-04-09 22:01 ` Suman Anna
2020-04-09 22:01 ` Suman Anna
2020-03-24 20:18 ` [PATCH 7/7] remoteproc/k3-r5: Add loading support for on-chip SRAM regions Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-03-24 20:18 ` Suman Anna
2020-04-10 20:30 ` Mathieu Poirier [this message]
2020-04-10 20:30 ` Mathieu Poirier
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=20200410203006.GA9146@xps15 \
--to=mathieu.poirier@linaro.org \
--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=robh+dt@kernel.org \
--cc=s-anna@ti.com \
/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: link
Be 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.