linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.
>> +}
>
>

  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).