From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Beleswar Padhi <b-padhi@ti.com>
Cc: andersson@kernel.org, afd@ti.com, hnagalla@ti.com,
u-kumar1@ti.com, jm@ti.com, jan.kiszka@siemens.com,
christophe.jaillet@wanadoo.fr, jkangas@redhat.com,
eballetbo@redhat.com, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v11 07/35] remoteproc: k3-r5: Use k3_r5_rproc_mem_data structure for memory info
Date: Wed, 7 May 2025 10:30:42 -0600 [thread overview]
Message-ID: <aBuKsolD-4_yzcZM@p14s> (raw)
In-Reply-To: <20250425104135.830255-8-b-padhi@ti.com>
On Fri, Apr 25, 2025 at 04:11:07PM +0530, Beleswar Padhi wrote:
> The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
> region addresses and names. Change this to use the k3_r5_rproc_mem_data
> structure to store memory information. This aligns with K3 DSP and M4
> drivers, and can be refactored out later.
>
> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> Reviewed-by: Andrew Davis <afd@ti.com>
> Tested-by: Judith Mendez <jm@ti.com>
> ---
> v11: Changelog:
> 1. Carried T/B tag.
>
> Link to v10:
> https://lore.kernel.org/all/20250417182001.3903905-8-b-padhi@ti.com/
>
> v10: Changelog:
> 1. Collected R/B from v9 version of this patch.
>
> Link to v9:
> https://lore.kernel.org/all/20250317120622.1746415-4-b-padhi@ti.com/
>
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 65 ++++++++++++++++++++----
> 1 file changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 5a460cfdfb4c4..e2dd5c38a0668 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -84,18 +84,44 @@ enum cluster_mode {
> CLUSTER_MODE_SINGLECORE
> };
>
> +/**
> + * struct k3_r5_mem_data - memory definitions for a R5
> + * @name: name for this memory entry
> + * @dev_addr: device address for the memory entry
> + */
> +struct k3_r5_mem_data {
> + const char *name;
> + const u32 dev_addr;
> +};
> +
> +/**
> + * struct k3_r5_dev_data - device data structure for a R5
> + * @mems: pointer to memory definitions for a R5
> + * @num_mems: number of memory regions in @mems
> + * @boot_align_addr: boot vector address alignment granularity
> + * @uses_lreset: flag to denote the need for local reset management
> + */
> +struct k3_r5_dev_data {
> + const struct k3_r5_mem_data *mems;
> + u32 num_mems;
> + u32 boot_align_addr;
> + bool uses_lreset;
> +};
> +
> /**
> * struct k3_r5_soc_data - match data to handle SoC variations
> * @tcm_is_double: flag to denote the larger unified TCMs in certain modes
> * @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for ECC
> * @single_cpu_mode: flag to denote if SoC/IP supports Single-CPU mode
> * @is_single_core: flag to denote if SoC/IP has only single core R5
> + * @core_data: pointer to R5-core-specific device data
> */
> struct k3_r5_soc_data {
> bool tcm_is_double;
> bool tcm_ecc_autoinit;
> bool single_cpu_mode;
> bool is_single_core;
> + const struct k3_r5_dev_data *core_data;
> };
>
> /**
> @@ -151,6 +177,7 @@ struct k3_r5_core {
> * @rmem: reserved memory regions data
> * @num_rmems: number of reserved memory regions
> * @reset: reset control handle
> + * @data: pointer to R5-core-specific device data
> * @tsp: TI-SCI processor control handle
> * @ti_sci: TI-SCI handle
> * @ti_sci_id: TI-SCI device identifier
> @@ -166,6 +193,7 @@ struct k3_r5_rproc {
> struct k3_r5_mem *rmem;
> int num_rmems;
> struct reset_control *reset;
> + const struct k3_r5_dev_data *data;
> struct ti_sci_proc *tsp;
> const struct ti_sci_handle *ti_sci;
> u32 ti_sci_id;
> @@ -1235,31 +1263,32 @@ static int k3_r5_rproc_configure_mode(struct k3_r5_rproc *kproc)
> static int k3_r5_core_of_get_internal_memories(struct platform_device *pdev,
> struct k3_r5_rproc *kproc)
> {
> - static const char * const mem_names[] = {"atcm", "btcm"};
> + const struct k3_r5_dev_data *data = kproc->data;
> struct device *dev = &pdev->dev;
> struct k3_r5_core *core = kproc->priv;
> struct resource *res;
> int num_mems;
> int i;
>
> - num_mems = ARRAY_SIZE(mem_names);
> - kproc->mem = devm_kcalloc(dev, num_mems, sizeof(*kproc->mem), GFP_KERNEL);
> + num_mems = kproc->data->num_mems;
num_mems = data->num_mems;
If this is the only thing I find then it is not worth a new revision. Let's see
how things play out. More comments to come.
Mathieu
> + 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,
> - mem_names[i]);
> + data->mems[i].name);
> if (!res) {
> dev_err(dev, "found no memory resource for %s\n",
> - mem_names[i]);
> + 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",
> - mem_names[i]);
> + data->mems[i].name);
> return -EBUSY;
> }
>
> @@ -1273,7 +1302,8 @@ static int k3_r5_core_of_get_internal_memories(struct platform_device *pdev,
> 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", mem_names[i]);
> + dev_err(dev, "failed to map %s memory\n",
> + data->mems[i].name);
> return -ENOMEM;
> }
> kproc->mem[i].bus_addr = res->start;
> @@ -1286,7 +1316,7 @@ static int k3_r5_core_of_get_internal_memories(struct platform_device *pdev,
> * addresses 0 and 0x41010000 (same as the bus address on AM65x
> * SoCs) based on loczrama setting
> */
> - if (!strcmp(mem_names[i], "atcm")) {
> + if (!strcmp(data->mems[i].name, "atcm")) {
> kproc->mem[i].dev_addr = core->loczrama ?
> 0 : K3_R5_TCM_DEV_ADDR;
> } else {
> @@ -1296,7 +1326,7 @@ static int k3_r5_core_of_get_internal_memories(struct platform_device *pdev,
> kproc->mem[i].size = resource_size(res);
>
> dev_dbg(dev, "memory %5s: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> - mem_names[i], &kproc->mem[i].bus_addr,
> + data->mems[i].name, &kproc->mem[i].bus_addr,
> kproc->mem[i].size, kproc->mem[i].cpu_addr,
> kproc->mem[i].dev_addr);
> }
> @@ -1408,6 +1438,7 @@ static int k3_r5_cluster_rproc_init(struct platform_device *pdev)
> kproc->priv = core;
> kproc->dev = cdev;
> kproc->rproc = rproc;
> + kproc->data = cluster->soc_data->core_data;
> core->kproc = kproc;
>
> kproc->ti_sci = devm_ti_sci_get_by_phandle(cdev, "ti,sci");
> @@ -1772,11 +1803,24 @@ static int k3_r5_probe(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct k3_r5_mem_data r5_mems[] = {
> + { .name = "atcm", .dev_addr = 0x0 },
> + { .name = "btcm", .dev_addr = K3_R5_TCM_DEV_ADDR },
> +};
> +
> +static const struct k3_r5_dev_data r5_data = {
> + .mems = r5_mems,
> + .num_mems = ARRAY_SIZE(r5_mems),
> + .boot_align_addr = 0,
> + .uses_lreset = true,
> +};
> +
> static const struct k3_r5_soc_data am65_j721e_soc_data = {
> .tcm_is_double = false,
> .tcm_ecc_autoinit = false,
> .single_cpu_mode = false,
> .is_single_core = false,
> + .core_data = &r5_data,
> };
>
> static const struct k3_r5_soc_data j7200_j721s2_soc_data = {
> @@ -1784,6 +1828,7 @@ static const struct k3_r5_soc_data j7200_j721s2_soc_data = {
> .tcm_ecc_autoinit = true,
> .single_cpu_mode = false,
> .is_single_core = false,
> + .core_data = &r5_data,
> };
>
> static const struct k3_r5_soc_data am64_soc_data = {
> @@ -1791,6 +1836,7 @@ static const struct k3_r5_soc_data am64_soc_data = {
> .tcm_ecc_autoinit = true,
> .single_cpu_mode = true,
> .is_single_core = false,
> + .core_data = &r5_data,
> };
>
> static const struct k3_r5_soc_data am62_soc_data = {
> @@ -1798,6 +1844,7 @@ static const struct k3_r5_soc_data am62_soc_data = {
> .tcm_ecc_autoinit = true,
> .single_cpu_mode = false,
> .is_single_core = true,
> + .core_data = &r5_data,
> };
>
> static const struct of_device_id k3_r5_of_match[] = {
> --
> 2.34.1
>
next prev parent reply other threads:[~2025-05-07 16:30 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 10:41 [PATCH v11 00/35] Refactor TI K3 R5, DSP and M4 Remoteproc Drivers Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 01/35] remoteproc: k3-r5: Drop check performed in k3_r5_rproc_{mbox_callback/kick} Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 02/35] remoteproc: k3-dsp: Drop check performed in k3_dsp_rproc_{mbox_callback/kick} Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 03/35] remoteproc: k3-r5: Refactor sequential core power up/down operations Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 04/35] remoteproc: k3-r5: Re-order internal memory initialization functions Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 05/35] remoteproc: k3-r5: Re-order k3_r5_release_tsp() function Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 06/35] remoteproc: k3-r5: Refactor Data Structures to Align with DSP and M4 Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 07/35] remoteproc: k3-r5: Use k3_r5_rproc_mem_data structure for memory info Beleswar Padhi
2025-05-07 16:30 ` Mathieu Poirier [this message]
2025-04-25 10:41 ` [PATCH v11 08/35] remoteproc: k3-{m4/dsp}: Add a void ptr member in rproc internal struct Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 09/35] remoteproc: k3-m4: Add pointer to rproc struct within k3_m4_rproc Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 10/35] remoteproc: k3-m4: Use k3_rproc_mem_data structure for memory info Beleswar Padhi
2025-05-07 16:48 ` Mathieu Poirier
2025-05-07 16:57 ` Mathieu Poirier
2025-04-25 10:41 ` [PATCH v11 11/35] remoteproc: k3: Refactor shared data structures Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 12/35] remoteproc: k3: Refactor mailbox rx_callback functions into common driver Beleswar Padhi
2025-05-08 15:46 ` Mathieu Poirier
2025-05-09 4:08 ` Beleswar Prasad Padhi
2025-04-25 10:41 ` [PATCH v11 13/35] remoteproc: k3: Refactor .kick rproc ops " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 14/35] remoteproc: k3-dsp: Correct Reset logic for devices without lresets Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 15/35] remoteproc: k3-m4: Introduce central function to put rproc into reset Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 16/35] remoteproc: k3: Refactor rproc_reset() implementation into common driver Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 17/35] remoteproc: k3-dsp: Correct Reset deassert logic for devices w/o lresets Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 18/35] remoteproc: k3-m4: Introduce central function to release rproc from reset Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 19/35] remoteproc: k3: Refactor rproc_release() implementation into common driver Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 20/35] remoteproc: k3-m4: Ping the mbox while acquiring the channel Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 21/35] remoteproc: k3: Refactor rproc_request_mbox() implementations into common driver Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 22/35] remoteproc: k3-dsp: Don't override rproc ops in IPC-only mode Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 23/35] remoteproc: k3-dsp: Assert local reset during .prepare callback Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 24/35] remoteproc: k3: Refactor .prepare rproc ops into common driver Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 25/35] remoteproc: k3: Refactor .unprepare " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 26/35] remoteproc: k3: Refactor .start " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 27/35] remoteproc: k3: Refactor .stop " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 28/35] remoteproc: k3: Refactor .attach " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 29/35] remoteproc: k3: Refactor .detach " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 30/35] remoteproc: k3: Refactor .get_loaded_rsc_table " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 31/35] remoteproc: k3: Refactor .da_to_va rproc " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 32/35] remoteproc: k3: Refactor of_get_memories() functions " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 33/35] remoteproc: k3: Refactor mem_release() " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 34/35] remoteproc: k3: Refactor reserved_mem_init() " Beleswar Padhi
2025-04-25 10:41 ` [PATCH v11 35/35] remoteproc: k3: Refactor release_tsp() " Beleswar Padhi
2025-04-25 22:42 ` [PATCH v11 00/35] Refactor TI K3 R5, DSP and M4 Remoteproc Drivers Andrew Davis
2025-05-02 15:16 ` Mathieu Poirier
2025-05-09 17:09 ` Mathieu Poirier
2025-05-12 4:08 ` Beleswar Prasad Padhi
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=aBuKsolD-4_yzcZM@p14s \
--to=mathieu.poirier@linaro.org \
--cc=afd@ti.com \
--cc=andersson@kernel.org \
--cc=b-padhi@ti.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=eballetbo@redhat.com \
--cc=hnagalla@ti.com \
--cc=jan.kiszka@siemens.com \
--cc=jkangas@redhat.com \
--cc=jm@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=u-kumar1@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.