From: Robin Murphy <robin.murphy@arm.com>
To: Alison Wang <alison.wang@nxp.com>,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: leoyang.li@nxp.com, xuelin.shi@nxp.com, xiaofeng.ren@nxp.com,
feng.guo@nxp.com
Subject: Re: [PATCH 1/8] ethosu: Add Arm Ethos-U driver
Date: Fri, 16 Jun 2023 16:49:10 +0100 [thread overview]
Message-ID: <84a7b27a-8a46-5f9c-105d-e00f066131e0@arm.com> (raw)
In-Reply-To: <20230616055913.2360-2-alison.wang@nxp.com>
On 2023-06-16 06:59, Alison Wang wrote:
[...]
> +/*
> + * The 'dma-ranges' device tree property for shared dma memory does not seem
> + * to be fully supported for coherent memory. Therefor we apply the DMA range
> + * offset ourselves.
> + */
NAK - if there's a bug in the core code, that wants to be fixed, not
bodged around by individual drivers. However from the look of the code
here, the driver appears to be misusing the property in an incorrect
manner anyway. But of course there's no devicetree binding here, so we
don't even really know what it thinks it expects... :/
I'd also agree with Greg that this is definitely not a firmware driver.
IIUC it's not so much a driver for the Ethos-U NPU itself, but one for
this particular subsystem configuration where requests to the NPU are
proxied through a dedicated Cortex-M core. As such, if you don't think
it belongs in drivers/accel, then drivers/remoteproc might be the next
most relevant choice. Also, is there a more specific name for this
particular subsystem, or is there a general expectation that this is the
only way an Ethos-U should ever be exposed to Linux, and it should never
have direct access to the hardware (as it would with an Ethos-N), and
thus there's no chance of ending up with multiple different "Ethos-U"
drivers in future?
Thanks,
Robin.
> +static dma_addr_t ethosu_buffer_dma_ranges(struct device *dev,
> + dma_addr_t dma_addr,
> + size_t dma_buf_size)
> +{
> + struct device_node *node = dev->of_node;
> + const __be32 *ranges;
> + int len;
> + int naddr;
> + int nsize;
> + int inc;
> + int i;
> +
> + if (!node)
> + return dma_addr;
> +
> + /* Get the #address-cells and #size-cells properties */
> + naddr = of_n_addr_cells(node);
> + nsize = of_n_size_cells(node);
> +
> + /* Read the 'dma-ranges' property */
> + ranges = of_get_property(node, "dma-ranges", &len);
> + if (!ranges || len <= 0)
> + return dma_addr;
> +
> + dev_dbg(dev, "ranges=%p, len=%d, naddr=%d, nsize=%d\n",
> + ranges, len, naddr, nsize);
> +
> + len /= sizeof(*ranges);
> + inc = naddr + naddr + nsize;
> +
> + for (i = 0; (i + inc) <= len; i += inc) {
> + dma_addr_t daddr;
> + dma_addr_t paddr;
> + dma_addr_t size;
> +
> + daddr = of_read_number(&ranges[i], naddr);
> + paddr = of_read_number(&ranges[i + naddr], naddr);
> + size = of_read_number(&ranges[i + naddr + naddr], nsize);
> +
> + dev_dbg(dev, "daddr=0x%llx, paddr=0x%llx, size=0x%llx\n",
> + daddr, paddr, size);
> +
> + if (dma_addr >= paddr &&
> + (dma_addr + dma_buf_size) < (paddr + size))
> + return dma_addr + daddr - paddr;
> + }
> +
> + return dma_addr;
> +}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Alison Wang <alison.wang@nxp.com>,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: leoyang.li@nxp.com, xuelin.shi@nxp.com, xiaofeng.ren@nxp.com,
feng.guo@nxp.com
Subject: Re: [PATCH 1/8] ethosu: Add Arm Ethos-U driver
Date: Fri, 16 Jun 2023 16:49:10 +0100 [thread overview]
Message-ID: <84a7b27a-8a46-5f9c-105d-e00f066131e0@arm.com> (raw)
In-Reply-To: <20230616055913.2360-2-alison.wang@nxp.com>
On 2023-06-16 06:59, Alison Wang wrote:
[...]
> +/*
> + * The 'dma-ranges' device tree property for shared dma memory does not seem
> + * to be fully supported for coherent memory. Therefor we apply the DMA range
> + * offset ourselves.
> + */
NAK - if there's a bug in the core code, that wants to be fixed, not
bodged around by individual drivers. However from the look of the code
here, the driver appears to be misusing the property in an incorrect
manner anyway. But of course there's no devicetree binding here, so we
don't even really know what it thinks it expects... :/
I'd also agree with Greg that this is definitely not a firmware driver.
IIUC it's not so much a driver for the Ethos-U NPU itself, but one for
this particular subsystem configuration where requests to the NPU are
proxied through a dedicated Cortex-M core. As such, if you don't think
it belongs in drivers/accel, then drivers/remoteproc might be the next
most relevant choice. Also, is there a more specific name for this
particular subsystem, or is there a general expectation that this is the
only way an Ethos-U should ever be exposed to Linux, and it should never
have direct access to the hardware (as it would with an Ethos-N), and
thus there's no chance of ending up with multiple different "Ethos-U"
drivers in future?
Thanks,
Robin.
> +static dma_addr_t ethosu_buffer_dma_ranges(struct device *dev,
> + dma_addr_t dma_addr,
> + size_t dma_buf_size)
> +{
> + struct device_node *node = dev->of_node;
> + const __be32 *ranges;
> + int len;
> + int naddr;
> + int nsize;
> + int inc;
> + int i;
> +
> + if (!node)
> + return dma_addr;
> +
> + /* Get the #address-cells and #size-cells properties */
> + naddr = of_n_addr_cells(node);
> + nsize = of_n_size_cells(node);
> +
> + /* Read the 'dma-ranges' property */
> + ranges = of_get_property(node, "dma-ranges", &len);
> + if (!ranges || len <= 0)
> + return dma_addr;
> +
> + dev_dbg(dev, "ranges=%p, len=%d, naddr=%d, nsize=%d\n",
> + ranges, len, naddr, nsize);
> +
> + len /= sizeof(*ranges);
> + inc = naddr + naddr + nsize;
> +
> + for (i = 0; (i + inc) <= len; i += inc) {
> + dma_addr_t daddr;
> + dma_addr_t paddr;
> + dma_addr_t size;
> +
> + daddr = of_read_number(&ranges[i], naddr);
> + paddr = of_read_number(&ranges[i + naddr], naddr);
> + size = of_read_number(&ranges[i + naddr + naddr], nsize);
> +
> + dev_dbg(dev, "daddr=0x%llx, paddr=0x%llx, size=0x%llx\n",
> + daddr, paddr, size);
> +
> + if (dma_addr >= paddr &&
> + (dma_addr + dma_buf_size) < (paddr + size))
> + return dma_addr + daddr - paddr;
> + }
> +
> + return dma_addr;
> +}
next prev parent reply other threads:[~2023-06-16 15:49 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-16 5:59 [PATCH 0/8] ethosu: Add Arm Ethos-U driver Alison Wang
2023-06-16 5:59 ` Alison Wang
2023-06-16 5:59 ` [PATCH 1/8] " Alison Wang
2023-06-16 5:59 ` Alison Wang
2023-06-16 6:25 ` Greg KH
2023-06-16 6:25 ` Greg KH
2023-06-16 8:28 ` [EXT] " Alison Wang
2023-06-16 8:28 ` Alison Wang
2023-06-16 15:08 ` Andrew Lunn
2023-06-16 15:08 ` Andrew Lunn
2023-07-06 6:01 ` Alison Wang
2023-07-06 6:01 ` Alison Wang
2023-06-16 6:26 ` Greg KH
2023-06-16 6:26 ` Greg KH
2023-06-16 8:28 ` [EXT] " Alison Wang
2023-06-16 8:28 ` Alison Wang
2023-06-16 10:42 ` kernel test robot
2023-06-16 10:42 ` kernel test robot
2023-06-16 15:49 ` Robin Murphy [this message]
2023-06-16 15:49 ` Robin Murphy
2023-06-16 17:16 ` kernel test robot
2023-06-16 17:16 ` kernel test robot
2023-06-24 18:30 ` kernel test robot
2023-06-24 18:30 ` kernel test robot
2023-06-16 5:59 ` [PATCH 2/8] ethosu: Use RPMsg messaging protocol based on i.MX Rpmsg implementation Alison Wang
2023-06-16 5:59 ` Alison Wang
2023-06-16 5:59 ` [PATCH 3/8] ethosu: Add inference type option for model and op Alison Wang
2023-06-16 5:59 ` Alison Wang
2023-06-16 5:59 ` [PATCH 4/8] ethosu: Add suspend/resume power management Alison Wang
2023-06-16 5:59 ` Alison Wang
2023-06-16 5:59 ` [PATCH 5/8] ethosu: Use ids for identifying messages sent to Ethos-U firmware Alison Wang
2023-06-16 5:59 ` Alison Wang
2023-06-16 5:59 ` [PATCH 6/8] ethosu: Add core message about network info Alison Wang
2023-06-16 5:59 ` Alison Wang
2023-06-16 5:59 ` [PATCH 7/8] ethosu: Add core message about inference cancellation Alison Wang
2023-06-16 5:59 ` Alison Wang
2023-06-16 16:13 ` kernel test robot
2023-06-16 16:13 ` kernel test robot
2023-06-16 5:59 ` [PATCH 8/8] ethosu: Add rwlock when alloc and remove msg id Alison Wang
2023-06-16 5:59 ` Alison Wang
2023-06-16 6:22 ` [PATCH 0/8] ethosu: Add Arm Ethos-U driver Greg KH
2023-06-16 6:22 ` Greg KH
2023-06-16 8:26 ` [EXT] " Alison Wang
2023-06-16 8:26 ` Alison Wang
2023-06-16 9:04 ` Greg KH
2023-06-16 9:04 ` Greg KH
2023-06-16 10:47 ` Alison Wang
2023-06-16 10:47 ` Alison Wang
2023-06-16 11:11 ` Greg KH
2023-06-16 11:11 ` Greg KH
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=84a7b27a-8a46-5f9c-105d-e00f066131e0@arm.com \
--to=robin.murphy@arm.com \
--cc=alison.wang@nxp.com \
--cc=feng.guo@nxp.com \
--cc=gregkh@linuxfoundation.org \
--cc=leoyang.li@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xiaofeng.ren@nxp.com \
--cc=xuelin.shi@nxp.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.