Re: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
Hello Ben,
On Mon, Aug 10, 2020 at 08:32:13PM -0700, Ben Levinsky wrote:
> +/**
> + * zynqmp_r5_release() - ZynqMP R5 device release function
> + * @dev: pointer to the device struct of ZynqMP R5
> + *
> + * Function to release ZynqMP R5 device.
> + */
> +static void zynqmp_r5_release(struct device *dev)
> +{
> + struct zynqmp_r5_pdata *pdata;
> + struct rproc *rproc;
> + struct sk_buff *skb;
> +
> + pdata = dev_get_drvdata(dev);
> + rproc = pdata->rproc;
> + if (rproc) {
> + rproc_del(rproc);
> + rproc_free(rproc);
> + }
> + if (pdata->tx_chan)
> + mbox_free_channel(pdata->tx_chan);
> + if (pdata->rx_chan)
> + mbox_free_channel(pdata->rx_chan);
> + /* Discard all SKBs */
> + while (!skb_queue_empty(>tx_mc_skbs)) {
> + skb = skb_dequeue(>tx_mc_skbs);
> + kfree_skb(skb);
In the event that zynqmp_r5_probe() fails before zynqmp_r5_setup_mbox()
has run, this will be called on an uninitialized skb_queue. (Also
obviously an issue once mailboxes are made optional again).
> + }
> +
> + put_device(dev->parent);
> +}
> +
> +/**
> + * event_notified_idr_cb() - event notified idr callback
> + * @id: idr id
> + * @ptr: pointer to idr private data
> + * @data: data passed to idr_for_each callback
> + *
> + * Pass notification to remoteproc virtio
> + *
> + * Return: 0. having return is to satisfy the idr_for_each() function
> + * pointer input argument requirement.
> + **/
> +static int event_notified_idr_cb(int id, void *ptr, void *data)
> +{
> + struct rproc *rproc = data;
> +
> + (void)rproc_vq_interrupt(rproc, id);
> + return 0;
> +}
> +
> +/**
> + * handle_event_notified() - remoteproc notification work funciton
> + * @work: pointer to the work structure
> + *
> + * It checks each registered remoteproc notify IDs.
> + */
> +static void handle_event_notified(struct work_struct *work)
> +{
> + struct rproc *rproc;
> + struct zynqmp_r5_pdata *pdata;
> +
> + pdata = container_of(work, struct zynqmp_r5_pdata, mbox_work);
> +
> + (void)mbox_send_message(pdata->rx_chan, NULL);
> + rproc = pdata->rproc;
> + /*
> + * We only use IPI for interrupt. The firmware side may or may
> + * not write the notifyid when it trigger IPI.
> + * And thus, we scan through all the registered notifyids.
> + */
> + idr_for_each(>notifyids, event_notified_idr_cb, rproc);
> +}
> +
> +/**
> + * zynqmp_r5_mb_rx_cb() - Receive channel mailbox callback
> + * @cl: mailbox client
> + * @mssg: message pointer
> + *
> + * It will schedule the R5 notification work.
> + */
> +static void zynqmp_r5_mb_rx_cb(struct mbox_client *cl, void *mssg)
> +{
> + struct zynqmp_r5_pdata *pdata;
> +
> + pdata = container_of(cl, struct zynqmp_r5_pdata, rx_mc);
> + if (mssg) {
> + struct zynqmp_ipi_message *ipi_msg, *buf_msg;
> + size_t len;
> +
> + ipi_msg = (struct zynqmp_ipi_message *)mssg;
> + buf_msg = (struct zynqmp_ipi_message *)pdata->rx_mc_buf;
> + len = (ipi_msg->len >= IPI_BUF_LEN_MAX) ?
> + IPI_BUF_LEN_MAX : ipi_msg->len;
> + buf_msg->len = len;
> + memcpy(buf_msg->data, ipi_msg->data, len);
> + }
> + schedule_work(>mbox_work);
> +}
> +
> +/**
> + * zynqmp_r5_mb_tx_done() - Request has been sent to the remote
> + * @cl: mailbox client
> + * @mssg: pointer to the message which has been sent
> + * @r: status of last TX - OK or error
> + *
> + * It will be called by the mailbox framework when the last TX has done.
> + */
> +static void zynqmp_r5_mb_tx_done(struct mbox_client *cl, void *mssg, int r)
> +{
> + struct zynqmp_r5_pdata *pdata;
> + struct sk_buff *skb;
> +
> + if (!mssg)
> + return;
> + pdata = container_of(cl, struct zynqmp_r5_pdata, tx_mc);
> + skb = skb_dequeue(>tx_mc_skbs);
> + kfree_skb(skb);
> +}
> +
> +/**
> + * zynqmp_r5_setup_mbox() - Setup mailboxes
> + *
> + * @pdata: pointer to the ZynqMP R5 processor platform data
> + * @node: pointer of the device node
> + *
> + * Function to setup mailboxes to talk to RPU.
> + *
> + * Return: 0 for success, negative value for failure.
> + */
> +static int zynqmp_r5_setup_mbox(struct zynqmp_r5_pdata *pdata,
> + struct device_node *node)
> +{
> + struct device *dev = >dev;
> + struct mbox_client *mclient;
> +
> + /* Setup TX mailbox channel client */
> + mclient = >tx_mc;
> + mclient->dev = dev;
> + mclient->rx_callback = NULL;
> + mclient->tx_block = false;
> + mclient->knows_txdone = false;
> + mclient->tx_done = zynqmp_r5_mb_tx_done;
> +
> + /* Setup TX mailbox channel client */
> + mclient = >rx_mc;
> + mclient->dev = dev;
> + mclient->rx_callback = zynqmp_r5_mb_rx_cb;
> + mclient->tx_block = false;
> + mclient->knows_txdone = false;
> +
> + INIT_WORK(>mbox_work,
RE: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
Hi Stefano
This is just response to few unanswered comments
Thanks
Ben
> -Original Message-
> From: linux-remoteproc-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Ben Levinsky
> Sent: Thursday, August 20, 2020 8:13 AM
> To: Stefano Stabellini
> Cc: Michal Simek ; devicet...@vger.kernel.org;
> mathieu.poir...@linaro.org; Ed T. Mooring ; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; Jiaying Liang ; linux-arm-
> ker...@lists.infradead.org
> Subject: RE: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
>
>
> > -Original Message-
> > From: Stefano Stabellini
> > Sent: Wednesday, August 19, 2020 2:21 PM
> > To: Ben Levinsky
> > Cc: Stefano Stabellini ; Michal Simek
> > ; devicet...@vger.kernel.org;
> > mathieu.poir...@linaro.org; Ed T. Mooring ; linux-
> > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > robh...@kernel.org; Jiaying Liang ; linux-arm-
> > ker...@lists.infradead.org
> > Subject: RE: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> > driver
> >
> > On Tue, 18 Aug 2020, Ben Levinsky wrote:
> > > > > +/**
> > > > > + * struct zynqmp_r5_mem - zynqmp rpu memory data
> > > > > + * @pnode_id: TCM power domain ids
> > > > > + * @res: memory resource
> > > > > + * @node: list node
> > > > > + */
> > > > > +struct zynqmp_r5_mem {
> > > > > + u32 pnode_id[MAX_MEM_PNODES];
> > > > > + struct resource res;
> > > > > + struct list_head node;
> > > > > +};
> > > > > +
> > > > > +/**
> > > > > + * struct zynqmp_r5_pdata - zynqmp rpu remote processor private
> data
> > > > > + * @dev: device of RPU instance
> > > > > + * @rproc: rproc handle
> > > > > + * @pnode_id: RPU CPU power domain id
> > > > > + * @mems: memory resources
> > > > > + * @is_r5_mode_set: indicate if r5 operation mode is set
> > > > > + * @tx_mc: tx mailbox client
> > > > > + * @rx_mc: rx mailbox client
> > > > > + * @tx_chan: tx mailbox channel
> > > > > + * @rx_chan: rx mailbox channel
> > > > > + * @mbox_work: mbox_work for the RPU remoteproc
> > > > > + * @tx_mc_skbs: socket buffers for tx mailbox client
> > > > > + * @rx_mc_buf: rx mailbox client buffer to save the rx message
> > > > > + */
> > > > > +struct zynqmp_r5_pdata {
> > > > > + struct device dev;
> > > > > + struct rproc *rproc;
> > > > > + u32 pnode_id;
> > > > > + struct list_head mems;
> > > > > + bool is_r5_mode_set;
> > > > > + struct mbox_client tx_mc;
> > > > > + struct mbox_client rx_mc;
> > > > > + struct mbox_chan *tx_chan;
> > > > > + struct mbox_chan *rx_chan;
> > > > > + struct work_struct mbox_work;
> > > > > + struct sk_buff_head tx_mc_skbs;
> > > > > + unsigned char rx_mc_buf[RX_MBOX_CLIENT_BUF_MAX];
> > > >
> > > > A simple small reordering of the struct fields would lead to small
> > > > memory savings due to alignment.
> > > >
> > > >
> > > [Ben Levinsky] will do. Do you mean ordering in either ascending or
> > descending order?
> >
> > Each field has a different alignment in the struct, so for example after
> > pnode_id there are probably 4 unused bytes because mems is 64bit
> > aligned.
> >
> >
> [Ben Levinsky] ok will update this so the alignments are done with less
> unused memory per struct allocation.
> > > > > +/*
> > > > > + * TCM needs mapping to R5 relative address and xilinx platform
> mgmt
> > call
> > > > > + */
> > > > > +struct rproc_mem_entry *handle_tcm_parsing(struct device *dev,
> > > > > + struct reserved_mem
> *rmem,
> > > > > + struct device_node *node,
> > > > > + int lookup_idx)
> > > > > +{
> > > > > + void *va;
> > > > > + dma_addr_t dma;
> > > > > + resource_size_t size;
> > > > > + int ret;
> > > > > + u32 pnode_id;
> > > > > + struct resource rsc;
> > >
RE: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
> -Original Message-
> From: Stefano Stabellini
> Sent: Wednesday, August 19, 2020 2:21 PM
> To: Ben Levinsky
> Cc: Stefano Stabellini ; Michal Simek
> ; devicet...@vger.kernel.org;
> mathieu.poir...@linaro.org; Ed T. Mooring ; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; Jiaying Liang ; linux-arm-
> ker...@lists.infradead.org
> Subject: RE: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
>
> On Tue, 18 Aug 2020, Ben Levinsky wrote:
> > > > +/**
> > > > + * struct zynqmp_r5_mem - zynqmp rpu memory data
> > > > + * @pnode_id: TCM power domain ids
> > > > + * @res: memory resource
> > > > + * @node: list node
> > > > + */
> > > > +struct zynqmp_r5_mem {
> > > > + u32 pnode_id[MAX_MEM_PNODES];
> > > > + struct resource res;
> > > > + struct list_head node;
> > > > +};
> > > > +
> > > > +/**
> > > > + * struct zynqmp_r5_pdata - zynqmp rpu remote processor private data
> > > > + * @dev: device of RPU instance
> > > > + * @rproc: rproc handle
> > > > + * @pnode_id: RPU CPU power domain id
> > > > + * @mems: memory resources
> > > > + * @is_r5_mode_set: indicate if r5 operation mode is set
> > > > + * @tx_mc: tx mailbox client
> > > > + * @rx_mc: rx mailbox client
> > > > + * @tx_chan: tx mailbox channel
> > > > + * @rx_chan: rx mailbox channel
> > > > + * @mbox_work: mbox_work for the RPU remoteproc
> > > > + * @tx_mc_skbs: socket buffers for tx mailbox client
> > > > + * @rx_mc_buf: rx mailbox client buffer to save the rx message
> > > > + */
> > > > +struct zynqmp_r5_pdata {
> > > > + struct device dev;
> > > > + struct rproc *rproc;
> > > > + u32 pnode_id;
> > > > + struct list_head mems;
> > > > + bool is_r5_mode_set;
> > > > + struct mbox_client tx_mc;
> > > > + struct mbox_client rx_mc;
> > > > + struct mbox_chan *tx_chan;
> > > > + struct mbox_chan *rx_chan;
> > > > + struct work_struct mbox_work;
> > > > + struct sk_buff_head tx_mc_skbs;
> > > > + unsigned char rx_mc_buf[RX_MBOX_CLIENT_BUF_MAX];
> > >
> > > A simple small reordering of the struct fields would lead to small
> > > memory savings due to alignment.
> > >
> > >
> > [Ben Levinsky] will do. Do you mean ordering in either ascending or
> descending order?
>
> Each field has a different alignment in the struct, so for example after
> pnode_id there are probably 4 unused bytes because mems is 64bit
> aligned.
>
>
[Ben Levinsky] ok will update this so the alignments are done with less unused
memory per struct allocation.
> > > > +/*
> > > > + * TCM needs mapping to R5 relative address and xilinx platform mgmt
> call
> > > > + */
> > > > +struct rproc_mem_entry *handle_tcm_parsing(struct device *dev,
> > > > + struct reserved_mem *rmem,
> > > > + struct device_node *node,
> > > > + int lookup_idx)
> > > > +{
> > > > + void *va;
> > > > + dma_addr_t dma;
> > > > + resource_size_t size;
> > > > + int ret;
> > > > + u32 pnode_id;
> > > > + struct resource rsc;
> > > > + struct rproc_mem_entry *mem;
> > > > +
> > > > + pnode_id = tcm_addr_to_pnode[lookup_idx][1];
> > > > + ret = zynqmp_pm_request_node(pnode_id,
> > > > +ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> > > > +ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> > > > + if (ret < 0) {
> > > > + dev_err(dev, "failed to request power node: %u\n",
> > > pnode_id);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + ret = of_address_to_resource(node, 0, );
> > > > + if (ret < 0) {
> > > > + dev_err(dev, "failed to get resource of memory %s",
> > > > + of_node_full_name(node));
> > > > + return -EINVAL;
> > > > +
RE: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
On Tue, 18 Aug 2020, Ben Levinsky wrote:
> > > +/**
> > > + * struct zynqmp_r5_mem - zynqmp rpu memory data
> > > + * @pnode_id: TCM power domain ids
> > > + * @res: memory resource
> > > + * @node: list node
> > > + */
> > > +struct zynqmp_r5_mem {
> > > + u32 pnode_id[MAX_MEM_PNODES];
> > > + struct resource res;
> > > + struct list_head node;
> > > +};
> > > +
> > > +/**
> > > + * struct zynqmp_r5_pdata - zynqmp rpu remote processor private data
> > > + * @dev: device of RPU instance
> > > + * @rproc: rproc handle
> > > + * @pnode_id: RPU CPU power domain id
> > > + * @mems: memory resources
> > > + * @is_r5_mode_set: indicate if r5 operation mode is set
> > > + * @tx_mc: tx mailbox client
> > > + * @rx_mc: rx mailbox client
> > > + * @tx_chan: tx mailbox channel
> > > + * @rx_chan: rx mailbox channel
> > > + * @mbox_work: mbox_work for the RPU remoteproc
> > > + * @tx_mc_skbs: socket buffers for tx mailbox client
> > > + * @rx_mc_buf: rx mailbox client buffer to save the rx message
> > > + */
> > > +struct zynqmp_r5_pdata {
> > > + struct device dev;
> > > + struct rproc *rproc;
> > > + u32 pnode_id;
> > > + struct list_head mems;
> > > + bool is_r5_mode_set;
> > > + struct mbox_client tx_mc;
> > > + struct mbox_client rx_mc;
> > > + struct mbox_chan *tx_chan;
> > > + struct mbox_chan *rx_chan;
> > > + struct work_struct mbox_work;
> > > + struct sk_buff_head tx_mc_skbs;
> > > + unsigned char rx_mc_buf[RX_MBOX_CLIENT_BUF_MAX];
> >
> > A simple small reordering of the struct fields would lead to small
> > memory savings due to alignment.
> >
> >
> [Ben Levinsky] will do. Do you mean ordering in either ascending or
> descending order?
Each field has a different alignment in the struct, so for example after
pnode_id there are probably 4 unused bytes because mems is 64bit
aligned.
> > > +/*
> > > + * TCM needs mapping to R5 relative address and xilinx platform mgmt call
> > > + */
> > > +struct rproc_mem_entry *handle_tcm_parsing(struct device *dev,
> > > + struct reserved_mem *rmem,
> > > + struct device_node *node,
> > > + int lookup_idx)
> > > +{
> > > + void *va;
> > > + dma_addr_t dma;
> > > + resource_size_t size;
> > > + int ret;
> > > + u32 pnode_id;
> > > + struct resource rsc;
> > > + struct rproc_mem_entry *mem;
> > > +
> > > + pnode_id = tcm_addr_to_pnode[lookup_idx][1];
> > > + ret = zynqmp_pm_request_node(pnode_id,
> > > + ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> > > + ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> > > + if (ret < 0) {
> > > + dev_err(dev, "failed to request power node: %u\n",
> > pnode_id);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + ret = of_address_to_resource(node, 0, );
> > > + if (ret < 0) {
> > > + dev_err(dev, "failed to get resource of memory %s",
> > > + of_node_full_name(node));
> > > + return -EINVAL;
> > > + }
> > > + size = resource_size();
> > > + va = devm_ioremap_wc(dev, rsc.start, size);
> > > + if (!va)
> > > + return -ENOMEM;
> > > +
> > > + /* zero out tcm base address */
> > > + if (rsc.start & 0xffe0) {
> > > + /* R5 can't see anything past 0xf so wipe it */
> > > + rsc.start &= 0x000f;
> >
> > If that is the case why not do:
> >
> > rsc.start &= 0x000f;
> >
> > unconditionally? if (rsc.start & 0xffe0) is superfluous.
> >
> > But I thought that actually the R5s could see TCM at both the low
> > address (< 0x000f) and also at the high address (i.e. 0xffe0).
> >
> >
> [Ben Levinsky] Here yes can make rsc.start &= 0x000f undconditional. Will
> update in v9 as such
> Also, this logic is because this is only for the Xilinx R5
> mappings of TCM banks that are at (from the TCM point of view) 0x0 and 0x2000
What I meant is that as far as I understand from the TRM the RPU should
also be able to access the same banks at the same address of the APU,
which I imagine is in the 0xffe0 range. But I could be wrong on
this.
If we could use the same addresses for RPU and APU, it would simplify
this driver.
> > > + /*
> > > + * handle tcm banks 1 a and b (0xffe9000 and
> > > + * 0xffeb)
> > > + */
> > > + if (rsc.start & 0x8)
> > > + rsc.start -= 0x9;
> >
> > It is very unclear to me why we have to do this
> >
> >
> [Ben Levinsky] This is for TCM bank 0B and bank 1B to map them to 0x0002
> so that the TCM relative addressing lines up. For example (0xffe9 &
> 0x000f) - 0x9 = 0x2
Could you please explain the mapping in an in-code comment?
The comment currently mentions 0xffe9000 and 0xffeb but:
- 0xffe9000 & 0x000f = 0xe9000
0xe9000 - 0x9 = 0x59000
- 0xffeb & 0x000f = 0xeb000
0xeb000 - 0x9 = 0xeb000
Either way we don't get 0x2. What am I missing?
>
RE: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
Hi Stefano Please see my comments inline > -Original Message- > From: Stefano Stabellini > Sent: Thursday, August 13, 2020 1:36 PM > To: Ben Levinsky > Cc: Stefano Stabellini ; Michal Simek > ; devicet...@vger.kernel.org; > mathieu.poir...@linaro.org; Ed T. Mooring ; linux- > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; > robh...@kernel.org; Michal Simek ; Jiaying Liang > ; Jason Wu ; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc > driver > > On Mon, 10 Aug 2020, Ben Levinsky wrote: > > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this > > remotproc driver, we can boot the R5 sub-system in different > > configurations. > > Which different configurations? How can you boot them? > [Ben Levinsky] The different configurations are R5 split and lockstep mode. Remoteproc boots the R5 up using Xilinx platform management firmware on a Microblaze core that has isolated access to power up/down. I will document as such in commit message for this patch in v9 > > > Signed-off-by: Ben Levinsky > > Signed-off-by: Wendy Liang > > Signed-off-by: Michal Simek > > Signed-off-by: Ed Mooring > > Signed-off-by: Jason Wu > > --- > > v2: > > - remove domain struct as per review from Mathieu > > v3: > > - add xilinx-related platform mgmt fn's instead of wrapping around > >function pointer in xilinx eemi ops struct > > v4: > > - add default values for enums > > - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1 > check > >are still raised as each is due to fixing the warning results in that > > particular line going over 80 characters. > > v5: > > - parse_fw change from use of rproc_of_resm_mem_entry_init to > > rproc_mem_entry_init and use of alloc/release > > - var's of type zynqmp_r5_pdata all have same local variable name > > - use dev_dbg instead of dev_info > > v6: > > - adding memory carveouts is handled much more similarly. All mem > > carveouts are > >now described in reserved memory as needed. That is, TCM nodes are not > >coupled to remoteproc anymore. This is reflected in the remoteproc R5 > > driver > >and the device tree binding. > > - remove mailbox from device tree binding as it is not necessary for elf > >loading > > - use lockstep-mode property for configuring RPU > > v7: > > - remove unused headers > > - change u32 *lockstep_mode -> u32 lockstep_mode; > > - change device-tree binding "lockstep-mode" to xlnx,cluster-mode > > - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at > >remoteproc-probe time > > - remove is_r5_mode_set from zynqmp rpu remote processor private data > > - do not error out if no mailbox is provided > > - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as > > pdata is > >handled in zynqmp_r5_remoteproc_remove > > v8: > > - remove old acks, reviewed-by's in commit message > > --- > > drivers/remoteproc/Kconfig| 10 + > > drivers/remoteproc/Makefile | 1 + > > drivers/remoteproc/zynqmp_r5_remoteproc.c | 911 > ++ > > 3 files changed, 922 insertions(+) > > create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c > > > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > > index c4d1731295eb..342a7e668636 100644 > > --- a/drivers/remoteproc/Kconfig > > +++ b/drivers/remoteproc/Kconfig > > @@ -249,6 +249,16 @@ config STM32_RPROC > > > > This can be either built-in or a loadable module. [Ben Levinsky] Right will update in v9 in the help message > > > > +config ZYNQMP_R5_REMOTEPROC > > + tristate "ZynqMP_R5 remoteproc support" > > + depends on ARM64 && PM && ARCH_ZYNQMP > > + select RPMSG_VIRTIO > > + select MAILBOX > > + select ZYNQMP_IPI_MBOX > > + help > > + Say y here to support ZynqMP R5 remote processors via the remote > > + processor framework. > > + > > endif # REMOTEPROC > > > > endmenu > > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile > > index e8b886e511f0..04d1c95d06d7 100644 > > --- a/drivers/remoteproc/Makefile > > +++ b/drivers/remoteproc/Makefile > > @@ -28,5 +28,6 @@ obj-$(CONFIG_QCOM_WCNSS_PIL) += > qcom_wcnss_pil.o > > qcom_wcnss_pil-y += qcom_wcnss.o > > qcom_wcnss_pil-y += qc
Re: [PATCH v8 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
On Mon, 10 Aug 2020, Ben Levinsky wrote: > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this > remotproc driver, we can boot the R5 sub-system in different > configurations. Which different configurations? How can you boot them? > Signed-off-by: Ben Levinsky > Signed-off-by: Wendy Liang > Signed-off-by: Michal Simek > Signed-off-by: Ed Mooring > Signed-off-by: Jason Wu > --- > v2: > - remove domain struct as per review from Mathieu > v3: > - add xilinx-related platform mgmt fn's instead of wrapping around >function pointer in xilinx eemi ops struct > v4: > - add default values for enums > - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1 > check >are still raised as each is due to fixing the warning results in that > particular line going over 80 characters. > v5: > - parse_fw change from use of rproc_of_resm_mem_entry_init to > rproc_mem_entry_init and use of alloc/release > - var's of type zynqmp_r5_pdata all have same local variable name > - use dev_dbg instead of dev_info > v6: > - adding memory carveouts is handled much more similarly. All mem > carveouts are >now described in reserved memory as needed. That is, TCM nodes are not >coupled to remoteproc anymore. This is reflected in the remoteproc R5 > driver >and the device tree binding. > - remove mailbox from device tree binding as it is not necessary for elf >loading > - use lockstep-mode property for configuring RPU > v7: > - remove unused headers > - change u32 *lockstep_mode -> u32 lockstep_mode; > - change device-tree binding "lockstep-mode" to xlnx,cluster-mode > - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at >remoteproc-probe time > - remove is_r5_mode_set from zynqmp rpu remote processor private data > - do not error out if no mailbox is provided > - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as > pdata is >handled in zynqmp_r5_remoteproc_remove > v8: > - remove old acks, reviewed-by's in commit message > --- > drivers/remoteproc/Kconfig| 10 + > drivers/remoteproc/Makefile | 1 + > drivers/remoteproc/zynqmp_r5_remoteproc.c | 911 ++ > 3 files changed, 922 insertions(+) > create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > index c4d1731295eb..342a7e668636 100644 > --- a/drivers/remoteproc/Kconfig > +++ b/drivers/remoteproc/Kconfig > @@ -249,6 +249,16 @@ config STM32_RPROC > > This can be either built-in or a loadable module. > > +config ZYNQMP_R5_REMOTEPROC > + tristate "ZynqMP_R5 remoteproc support" > + depends on ARM64 && PM && ARCH_ZYNQMP > + select RPMSG_VIRTIO > + select MAILBOX > + select ZYNQMP_IPI_MBOX > + help > + Say y here to support ZynqMP R5 remote processors via the remote > + processor framework. > + > endif # REMOTEPROC > > endmenu > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile > index e8b886e511f0..04d1c95d06d7 100644 > --- a/drivers/remoteproc/Makefile > +++ b/drivers/remoteproc/Makefile > @@ -28,5 +28,6 @@ obj-$(CONFIG_QCOM_WCNSS_PIL)+= > qcom_wcnss_pil.o > qcom_wcnss_pil-y += qcom_wcnss.o > qcom_wcnss_pil-y += qcom_wcnss_iris.o > obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o > +obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC) += zynqmp_r5_remoteproc.o > obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o > obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o > diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c > b/drivers/remoteproc/zynqmp_r5_remoteproc.c > new file mode 100644 > index ..b600759e257e > --- /dev/null > +++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c I tried to build this but I get 4 warnings: drivers/remoteproc/zynqmp_r5_remoteproc.c: In function 'handle_tcm_parsing': drivers/remoteproc/zynqmp_r5_remoteproc.c:286:10: warning: return makes pointer from integer without a cast [-Wint-conversion] return -EINVAL; ^ drivers/remoteproc/zynqmp_r5_remoteproc.c:293:10: warning: return makes pointer from integer without a cast [-Wint-conversion] return -EINVAL; ^ drivers/remoteproc/zynqmp_r5_remoteproc.c:298:10: warning: return makes pointer from integer without a cast [-Wint-conversion] return -ENOMEM; ^ drivers/remoteproc/zynqmp_r5_remoteproc.c:317:10: warning: return makes pointer from integer without a cast [-Wint-conversion] return -ENOMEM; Please fix all warnings before submitting to the list. > @@ -0,0 +1,911 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Zynq R5 Remote Processor driver > + * > + * Copyright (C) 2019, 2020 Xilinx Inc. Ben Levinsky > > + * Copyright (C) 2015 - 2018 Xilinx Inc. > + * Copyright (C) 2015 Jason Wu > + * > + * Based on origin OMAP and Zynq Remote Processor driver > + * > + *
