From: Tanmay Shah <tanmay.shah@xilinx.com>
To: Lars-Peter Clausen <lars@metafoo.de>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Michal Simek <michal.simek@xilinx.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Ben Levinsky <ben.levinsky@xilinx.com>,
Bill Mills <bill.mills@linaro.org>,
"Sergei Korneichuk" <sergei.korneichuk@xilinx.com>,
<linux-remoteproc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 6/6] drivers: remoteproc: Add Xilinx r5 remoteproc driver
Date: Tue, 14 Dec 2021 01:01:03 +0530 [thread overview]
Message-ID: <acbd7749-7bb2-0de2-5658-2b62ace9520a@xilinx.com> (raw)
In-Reply-To: <ab9e009a-5e35-ae49-2c8e-65be6ba36d7f@metafoo.de>
On 12/13/21 4:38 PM, Lars-Peter Clausen wrote:
> On 11/23/21 7:20 AM, Tanmay Shah wrote:
>> [...]
>> +/*
>> + * zynqmp_r5_rproc_mem_map
>> + * @rproc: single R5 core's corresponding rproc instance
>> + * @mem: mem entry to map
>> + *
>> + * Callback to map va for memory-region's carveout.
>> + *
>> + * return 0 on success, otherwise non-zero value on failure
>> + */
>> +static int zynqmp_r5_rproc_mem_map(struct rproc *rproc,
>> + struct rproc_mem_entry *mem)
>> +{
>> + void __iomem *va;
>> +
>> + va = ioremap_wc(mem->dma, mem->len);
>
> Since you want normal memory and not IO memory a better choice might
> be memremap() with MEMREMAP_WC. Internally memremap() will call
> ioremap_wc(), but this will make the intention clear and you do not
> have to deal with the __iomem type cast.
>
Thanks Lars-Peter. Yes you are right. I found this article
https://lwn.net/Articles/653585/ about use of memremap after I posted
this patchset and I have planned to replace ioremap_wc function with
memremap with MEMREMAP_WC flag.
>> + if (IS_ERR_OR_NULL(va))
>> + return -ENOMEM;
>> +
>> + mem->va = (void *)va;
>> +
>> + return 0;
>> +}
>> [...]
>>
>> +static int add_tcm_banks(struct rproc *rproc)
>> +{
>> + struct device *dev;
>> + struct platform_device *parent_pdev;
>> + struct zynqmp_r5_cluster *cluster;
>> + struct zynqmp_r5_core *r5_core;
>> +
>> + r5_core = (struct zynqmp_r5_core *)rproc->priv;
>> + if (!r5_core)
>> + return -EINVAL;
>> +
>> + dev = r5_core->dev;
>> + if (!dev) {
>> + pr_err("r5 core device unavailable\n");
>> + return -ENODEV;
>> + }
>> +
>> + parent_pdev = to_platform_device(dev->parent);
>> + if (!parent_pdev) {
>> + dev_err(dev, "parent platform dev unavailable\n");
>> + return -ENODEV;
>> + }
>> +
>> + cluster = platform_get_drvdata(parent_pdev);
>
> You could just use dev_get_drvdata() without having to cast back to
> the platform_device first.
>
>
>> + if (!cluster) {
>> + dev_err(&parent_pdev->dev, "Invalid driver data\n");
>> + return -EINVAL;
>> + }
>> +
>> + if (cluster->mode == SPLIT_MODE)
>> + return add_tcm_carveout_split_mode(rproc);
>> + else if (cluster->mode == LOCKSTEP_MODE)
>> + return add_tcm_carveout_lockstep_mode(rproc);
>> +
>> + dev_err(cluster->dev, "invalid cluster mode\n");
>> + return -EINVAL;
>> +}
>> +
>> [...]
>> +
>> +static struct rproc_ops zynqmp_r5_rproc_ops = {
> const
>> + .start = zynqmp_r5_rproc_start,
>> + .stop = zynqmp_r5_rproc_stop,
>> + .load = rproc_elf_load_segments,
>> + .parse_fw = zynqmp_r5_parse_fw,
>> + .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
>> + .sanity_check = rproc_elf_sanity_check,
>> + .get_boot_addr = rproc_elf_get_boot_addr,
>> +};
>> [....]
>> +static int zynqmp_r5_get_mem_region_node(struct zynqmp_r5_core
>> *r5_core)
>> +{
>> [...]
>> +
>> + for (i = 0; i < res_mem_count; i++) {
>> + rmem_np = of_parse_phandle(np, "memory-region", i);
>> + if (!rmem_np)
>> + return -EINVAL;
>> +
>> + rmem = of_reserved_mem_lookup(rmem_np);
>> + if (!rmem) {
>> + of_node_put(rmem_np);
>> + return -EINVAL;
>> + }
>> +
>> + memcpy(&r5_core->res_mem[i], rmem,
>> + sizeof(struct reserved_mem));
>
> r5_core->res_mem[i] = *mem;
>
> This will give you proper type checking and is also a bit shorter.
>
>> + of_node_put(rmem_np);
>> + }
>> +
>> + r5_core->res_mem_count = res_mem_count;
>> +
>> + return 0;
>> +}
>> [...]
>> +
>> +static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>> +{
>> [...]
>> +
>>
>> + i = 0;
>> + for_each_available_child_of_node(dev_node, child) {
>> + child_pdev = of_find_device_by_node(child);
>> + if (!child_pdev)
> A return or a break in a for_each_available_child_of_node() will leak
> the reference to the child node.
Do you mean I have to use of_put_node for each child?
>> [...]
>> + }
>> +
>> [...]
>> +
>> + return 0;
>> +}
>> +
>> +static void zynqmp_r5_cluster_exit(void *data)
>> +{
>> + struct platform_device *pdev = (struct platform_device *)data;
>> +
>> + platform_set_drvdata(pdev, NULL);
> This is not needed. The device driver core will set drvdata to NULL
> when the device is removed.
>> +
>> + pr_info("Exit r5f subsystem driver\n");
> This is probably also not needed.
>> +}
>
>
next prev parent reply other threads:[~2021-12-13 19:31 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 6:20 [PATCH v2 0/6] Add Xilinx RPU subsystem support Tanmay Shah
2021-11-23 6:20 ` [PATCH v2 1/6] dt-bindings: remoteproc: Add Xilinx RPU subsystem bindings Tanmay Shah
2021-11-23 6:20 ` [PATCH v2 2/6] arm64: dts: xilinx: zynqmp: Add RPU subsystem device node Tanmay Shah
2021-11-29 17:58 ` Mathieu Poirier
2021-11-30 8:01 ` Tanmay Shah
2021-11-23 6:20 ` [PATCH v2 3/6] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration Tanmay Shah
2021-11-23 6:20 ` [PATCH v2 4/6] firmware: xilinx: Add shutdown/wakeup APIs Tanmay Shah
2021-11-23 6:20 ` [PATCH v2 5/6] firmware: xilinx: Add RPU configuration APIs Tanmay Shah
2021-11-23 6:20 ` [PATCH v2 6/6] drivers: remoteproc: Add Xilinx r5 remoteproc driver Tanmay Shah
2021-11-29 18:42 ` Mathieu Poirier
2021-11-30 8:01 ` Tanmay Shah
2021-11-30 20:14 ` Mathieu Poirier
2021-12-01 18:37 ` Tanmay Shah
2021-12-03 18:55 ` Mathieu Poirier
2021-12-06 11:03 ` Tanmay Shah
2021-12-13 8:10 ` Tanmay Shah
2021-12-13 18:39 ` Mathieu Poirier
2021-12-06 19:04 ` Mathieu Poirier
2021-12-13 19:11 ` Tanmay Shah
2021-12-07 18:31 ` Mathieu Poirier
2021-12-13 19:17 ` Tanmay Shah
2022-02-07 18:57 ` Tanmay Shah
2022-02-08 16:54 ` Mathieu Poirier
2022-02-09 10:23 ` Tanmay Shah
2021-12-13 11:08 ` Lars-Peter Clausen
2021-12-13 19:31 ` Tanmay Shah [this message]
2021-12-13 19:43 ` Lars-Peter Clausen
2021-12-13 19:46 ` Tanmay Shah
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=acbd7749-7bb2-0de2-5658-2b62ace9520a@xilinx.com \
--to=tanmay.shah@xilinx.com \
--cc=ben.levinsky@xilinx.com \
--cc=bill.mills@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=lars@metafoo.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=michal.simek@xilinx.com \
--cc=robh+dt@kernel.org \
--cc=sergei.korneichuk@xilinx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).