- Openamp-system-reference - lists.openampproject.org

by Chan King Choy, Nathalie

[Shortening to 30 min, as Dan's partly-conflicting series has now been established and begins this week, so let's just start at half-past.] First meeting of 2023. Agenda: * Bill: What are the 2023 HPP objectives? * All: Discuss brainstorm list<https://docs.google.com/document/d/19Bpss2PHw8xavpviWZ1vu45hxrIbBG8mSSgKhrE…> on what makes sense to work on next * Nathalie: Scheduling 2023 meeting series [https://st2.zoom.us/static/6.3.10219/image/new/ZoomLogo_110_25.png]<… [View More]https://zoom.us/> Hi there, Nathalie Chan King Choy is inviting you to a scheduled Zoom meeting. Join Zoom Meeting<https://xilinx.zoom.us/j/91913123613?pwd=TVl6UldtR1k1R3RVY3ZueEdOQ1A2UT09&f…> Phone one-tap: US: +16699006833,,91913123613#,,,,,,0#,,3787125748#<tel:+16699006833,,91913123613#,,,,,,0#,,3787125748#> or +17209289299,,91913123613#,,,,,,0#,,3787125748#<tel:+17209289299,,91913123613#,,,,,,0#,,3787125748#> Meeting URL: https://xilinx.zoom.us/j/91913123613?pwd=TVl6UldtR1k1R3RVY3ZueEdOQ1A2UT09&f… Meeting ID: 919 1312 3613 Passcode: KxRC6Aut@y Join by Telephone For higher quality, dial a number based on your current location. Dial: US: +1 669 900 6833 or +1 720 928 9299 or +1 929 205 6099 or 888 475 4499 (Toll Free) or 833 548 0276 (Toll Free) or 833 548 0282 (Toll Free) or 877 853 5257 (Toll Free) India: +91 446 480 2722 or +91 806 480 2722 or +91 80 71 279 440 or +91 116 480 2722 or +91 22 48 798 004 or +91 224 879 8012 or +91 225 097 2744 or +91 225 097 2745 or +91 226 480 2722 or +91 22 71 279 525 or +91 406 480 2722 or 000 800 050 5050 (Toll Free) or 000 800 001 4002 (Toll Free) Ireland: +353 1 536 9320 or +353 1 653 3895 or +353 6 163 9031 or 1800 901 561 (Toll Free) or 1800 943 965 (Toll Free) or 1800 949 238 (Toll Free) Singapore: +65 3165 1065 or +65 3158 7288 or 1800 407 5602 (Toll Free) or 800 101 3814 (Toll Free) or 800 852 6054 (Toll Free) Meeting ID: 919 1312 3613 Passcode: 3787125748 International numbers<https://xilinx.zoom.us/u/aeBuTEAkLY> Join from a Video Conference room system Meeting ID: 919 1312 3613 Passcode: 3787125748 US: 91913123613(a)global.zoomcrc.com<mailto:91913123613@global.zoomcrc.com> Passcode: 3787125748 APAC: 91913123613(a)global.zoomcrc.com<mailto:91913123613@global.zoomcrc.com> Passcode: 3787125748 India: 91913123613(a)global.zoomcrc.com<mailto:91913123613@global.zoomcrc.com> Passcode: 3787125748 Europe: 91913123613(a)global.zoomcrc.com<mailto:91913123613@global.zoomcrc.com> Passcode: 3787125748 SIP: 91913123613(a)zoomcrc.com<mailto:91913123613@zoomcrc.com> Passcode: 3787125748 [View Less]

2 years, 3 months

1
0
0 0

[PATCH] remoteproc: xilinx: add mailbox channels for rpmsg

by Tanmay Shah

This patch makes each r5 core mailbox client and uses tx and rx channels to send and receive data to/from remote processor respectively. This is needed for rpmsg communication to remote processor. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> --- drivers/remoteproc/xlnx_r5_remoteproc.c | 329 +++++++++++++++++++----- 1 file changed, 271 insertions(+), 58 deletions(-) diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c index 2db57d394155..… [View More]1e797c5ffc06 100644 --- a/drivers/remoteproc/xlnx_r5_remoteproc.c +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c @@ -8,16 +8,23 @@ #include <linux/dma-mapping.h> #include <linux/firmware/xlnx-zynqmp.h> #include <linux/kernel.h> +#include <linux/mailbox_client.h> +#include <linux/mailbox/zynqmp-ipi-message.h> #include <linux/module.h> #include <linux/of_address.h> #include <linux/of_platform.h> #include <linux/of_reserved_mem.h> #include <linux/platform_device.h> #include <linux/remoteproc.h> -#include <linux/slab.h> #include "remoteproc_internal.h" +/* IPI buffer MAX length */ +#define IPI_BUF_LEN_MAX 32U + +/* RX mailbox client buffer max length */ +#define MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \ + sizeof(struct zynqmp_ipi_message)) /* * settings for RPU cluster mode which * reflects possible values of xlnx,cluster-mode dt-property @@ -65,6 +72,12 @@ static const struct mem_bank_data zynqmp_tcm_banks[] = { * @rmem: reserved memory region nodes from device tree * @rproc: rproc handle * @pm_domain_id: RPU CPU power domain id + * @rx_mc_buf: to copy data from mailbox rx channel + * @tx_mc_buf: to copy data to mailbox tx channel + * @mbox_work: schedule work after receiving data from mailbox + * @mbox_cl: mailbox client + * @tx_chan: mailbox tx channel + * @rx_chan: mailbox rx channel */ struct zynqmp_r5_core { struct device *dev; @@ -75,6 +88,14 @@ struct zynqmp_r5_core { struct reserved_mem **rmem; struct rproc *rproc; u32 pm_domain_id; + + /* mailbox related data structures */ + unsigned char rx_mc_buf[MBOX_CLIENT_BUF_MAX]; + unsigned char tx_mc_buf[MBOX_CLIENT_BUF_MAX]; + struct work_struct mbox_work; + struct mbox_client mbox_cl; + struct mbox_chan *tx_chan; + struct mbox_chan *rx_chan; }; /** @@ -92,6 +113,181 @@ struct zynqmp_r5_cluster { struct zynqmp_r5_core **r5_cores; }; +/** + * event_notified_idr_cb() - callback for vq_interrupt per notifyid + * @id: rproc->notify 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; + + if (rproc_vq_interrupt(rproc, id) == IRQ_NONE) + dev_dbg(&rproc->dev, "data not found for vqid=%d\n", id); + + return 0; +} + +/** + * handle_event_notified() - remoteproc notification work function + * @work: pointer to the work structure + * + * It checks each registered remoteproc notify IDs. + */ +static void handle_event_notified(struct work_struct *work) +{ + struct zynqmp_r5_core *r5_core; + struct rproc *rproc; + + r5_core = container_of(work, struct zynqmp_r5_core, mbox_work); + rproc = r5_core->rproc; + + /* + * We only use IPI for interrupt. The RPU firmware side may or may + * not write the notifyid when it trigger IPI. + * And thus, we scan through all the registered notifyids and + * find which one is valid to get the message. + * Even if message from firmware is NULL, we attempt to get vqid + */ + idr_for_each(&rproc->notifyids, event_notified_idr_cb, rproc); +} + +/** + * zynqmp_r5_mb_rx_cb() - receive channel mailbox callback + * @cl: mailbox client + * @msg: message pointer + * + * Receive data from ipi buffer, ack interrupt and then + * it will schedule the R5 notification work. + */ +static void zynqmp_r5_mb_rx_cb(struct mbox_client *cl, void *msg) +{ + struct zynqmp_ipi_message *ipi_msg, *buf_msg; + struct zynqmp_r5_core *r5_core; + size_t len; + + r5_core = container_of(cl, struct zynqmp_r5_core, mbox_cl); + + /* copy data from ipi buffer to r5_core */ + ipi_msg = (struct zynqmp_ipi_message *)msg; + buf_msg = (struct zynqmp_ipi_message *)r5_core->rx_mc_buf; + len = ipi_msg->len; + if (len > IPI_BUF_LEN_MAX) { + dev_warn(r5_core->dev, "msg size exceeded than %d\n", + IPI_BUF_LEN_MAX); + len = IPI_BUF_LEN_MAX; + } + buf_msg->len = len; + memcpy(buf_msg->data, ipi_msg->data, len); + + /* received and processed interrupt ack */ + if (mbox_send_message(r5_core->rx_chan, NULL) < 0) + dev_err(r5_core->dev, "ack failed to mbox rx_chan\n"); + + schedule_work(&r5_core->mbox_work); +} + +/** + * zynqmp_r5_setup_mbox() - Setup mailboxes related properties + * this is used for each individual R5 core + * + * @r5_core: pointer to the ZynqMP r5 core data + * + * Function to setup mailboxes related properties + * + */ +static void zynqmp_r5_setup_mbox(struct zynqmp_r5_core *r5_core) +{ + struct zynqmp_r5_cluster *cluster; + struct mbox_client *mbox_cl; + + cluster = dev_get_drvdata(r5_core->dev->parent); + + /** + * ToDo: Use only one IPI channel for APU to communicate with both RPUs + * in split mode. As of now, two IPI channels are expeceted for APU + * to communicate with RPU. for example, APU(IPI0)<-> RPU0(IPI1) and + * APU(IPI7)<->RPU1(IPI2). However, this is not the optimized use + * of the hardware. As per hardware reference manual, each IPI channel + * can receive interrupt from another IPI channel. So APU must be able + * to communicate with both RPUs simultaneously using same IPI channel. + * For example, this is valid case: APU(IPI0)<->RPU0(IPI1) and + * APU(IPI0)<->RPU1(IPI2). However, with current available examples + * and RPU firmware, this configuration in device-tree is causing system-crash. + * And so, using extra IPI channel is required in device-tree. In split + * mode explicitly inform user about this limitation and requirement. + */ + if (cluster->mode == SPLIT_MODE) + dev_warn(r5_core->dev, "split mode: APU should use two IPI channels\n"); + + mbox_cl = &r5_core->mbox_cl; + mbox_cl->rx_callback = zynqmp_r5_mb_rx_cb; + mbox_cl->tx_block = false; + mbox_cl->knows_txdone = false; + mbox_cl->tx_done = NULL; + mbox_cl->dev = r5_core->dev; + + /* Request TX and RX channels */ + r5_core->tx_chan = mbox_request_channel_byname(mbox_cl, "tx"); + if (IS_ERR(r5_core->tx_chan)) { + r5_core->tx_chan = NULL; + return; + } + + r5_core->rx_chan = mbox_request_channel_byname(mbox_cl, "rx"); + if (IS_ERR(r5_core->rx_chan)) { + mbox_free_channel(r5_core->tx_chan); + r5_core->rx_chan = NULL; + r5_core->tx_chan = NULL; + return; + } + + INIT_WORK(&r5_core->mbox_work, handle_event_notified); +} + +static void zynqmp_r5_free_mbox(struct zynqmp_r5_core *r5_core) +{ + if (r5_core->tx_chan) { + mbox_free_channel(r5_core->tx_chan); + r5_core->tx_chan = NULL; + } + + if (r5_core->rx_chan) { + mbox_free_channel(r5_core->rx_chan); + r5_core->rx_chan = NULL; + } +} + +/* + * zynqmp_r5_core_kick() - kick a firmware if mbox is provided + * @rproc: r5 core's corresponding rproc structure + * @vqid: virtqueue ID + */ +static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid) +{ + struct zynqmp_r5_core *r5_core = rproc->priv; + struct device *dev = r5_core->dev; + struct zynqmp_ipi_message *mb_msg; + int ret; + + /* don't handle kick if mbox setup failed for this core */ + if (!r5_core->tx_chan && !r5_core->rx_chan) + return; + + mb_msg = (struct zynqmp_ipi_message *)r5_core->tx_mc_buf; + memcpy(mb_msg->data, &vqid, sizeof(vqid)); + mb_msg->len = sizeof(vqid); + ret = mbox_send_message(r5_core->tx_chan, mb_msg); + if (ret < 0) + dev_warn(dev, "failed to send message\n"); +} + /* * zynqmp_r5_set_mode() * @@ -227,6 +423,63 @@ static int zynqmp_r5_mem_region_unmap(struct rproc *rproc, return 0; } +/** + * zynqmp_r5_get_mem_region_node() + * parse memory-region property and get reserved mem regions + * + * @r5_core: pointer to zynqmp_r5_core type object + * + * Return: 0 for success and error code for failure. + */ +static int zynqmp_r5_get_mem_region_node(struct zynqmp_r5_core *r5_core) +{ + struct device_node *np, *rmem_np; + struct reserved_mem **rmem; + int res_mem_count, i; + struct device *dev; + + dev = r5_core->dev; + np = r5_core->np; + + res_mem_count = of_property_count_elems_of_size(np, "memory-region", + sizeof(phandle)); + + if (res_mem_count <= 0) { + dev_warn(dev, "failed to get memory-region property %d\n", + res_mem_count); + return 0; + } + + if (!r5_core->tx_chan && !r5_core->rx_chan) + res_mem_count = 1; + + rmem = devm_kcalloc(dev, res_mem_count, + sizeof(struct reserved_mem *), GFP_KERNEL); + if (!rmem) + return -ENOMEM; + + for (i = 0; i < res_mem_count; i++) { + rmem_np = of_parse_phandle(np, "memory-region", i); + if (!rmem_np) + goto release_rmem; + + rmem[i] = of_reserved_mem_lookup(rmem_np); + if (!rmem[i]) { + of_node_put(rmem_np); + goto release_rmem; + } + + of_node_put(rmem_np); + } + + r5_core->rmem_count = res_mem_count; + r5_core->rmem = rmem; + return 0; + +release_rmem: + return -EINVAL; +} + /* * add_mem_regions_carveout() * @rproc: single R5 core's corresponding rproc instance @@ -572,6 +825,20 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc) return ret; } + /* + * If mailbox nodes are disabled using "status" property then setting up + * mailbox channels will be failed and in that case, we don't need vrings + * and vdevbuffer for this core. So, setup mailbox before parsing + * memory-region property. If "tx" and "rx" mailboxes are not setup, then + * only parse and add first memory-region carveout. As per bindings, it + * must be firmware load region + */ + zynqmp_r5_setup_mbox(rproc->priv); + + ret = zynqmp_r5_get_mem_region_node(rproc->priv); + if (ret) + dev_warn(&rproc->dev, "memory-region prop failed %d\n", ret); + ret = add_mem_regions_carveout(rproc); if (ret) { dev_err(&rproc->dev, "failed to get reserve mem regions %d\n", ret); @@ -597,6 +864,8 @@ static int zynqmp_r5_rproc_unprepare(struct rproc *rproc) r5_core = (struct zynqmp_r5_core *)rproc->priv; + zynqmp_r5_free_mbox(r5_core); + for (i = 0; i < r5_core->tcm_bank_count; i++) { pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id; if (zynqmp_pm_release_node(pm_domain_id)) @@ -617,6 +886,7 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = { .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table, .sanity_check = rproc_elf_sanity_check, .get_boot_addr = rproc_elf_get_boot_addr, + .kick = zynqmp_r5_rproc_kick, }; /** @@ -726,59 +996,6 @@ static int zynqmp_r5_get_tcm_node(struct zynqmp_r5_cluster *cluster) return 0; } -/** - * zynqmp_r5_get_mem_region_node() - * parse memory-region property and get reserved mem regions - * - * @r5_core: pointer to zynqmp_r5_core type object - * - * Return: 0 for success and error code for failure. - */ -static int zynqmp_r5_get_mem_region_node(struct zynqmp_r5_core *r5_core) -{ - struct device_node *np, *rmem_np; - struct reserved_mem **rmem; - int res_mem_count, i; - struct device *dev; - - dev = r5_core->dev; - np = r5_core->np; - - res_mem_count = of_property_count_elems_of_size(np, "memory-region", - sizeof(phandle)); - if (res_mem_count <= 0) { - dev_warn(dev, "failed to get memory-region property %d\n", - res_mem_count); - return 0; - } - - rmem = devm_kcalloc(dev, res_mem_count, - sizeof(struct reserved_mem *), GFP_KERNEL); - if (!rmem) - return -ENOMEM; - - for (i = 0; i < res_mem_count; i++) { - rmem_np = of_parse_phandle(np, "memory-region", i); - if (!rmem_np) - goto release_rmem; - - rmem[i] = of_reserved_mem_lookup(rmem_np); - if (!rmem[i]) { - of_node_put(rmem_np); - goto release_rmem; - } - - of_node_put(rmem_np); - } - - r5_core->rmem_count = res_mem_count; - r5_core->rmem = rmem; - return 0; - -release_rmem: - return -EINVAL; -} - /* * zynqmp_r5_core_init() * Create and initialize zynqmp_r5_core type object @@ -806,10 +1023,6 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster, for (i = 0; i < cluster->core_count; i++) { r5_core = cluster->r5_cores[i]; - ret = zynqmp_r5_get_mem_region_node(r5_core); - if (ret) - dev_warn(dev, "memory-region prop failed %d\n", ret); - /* Initialize r5 cores with power-domains parsed from dts */ ret = of_property_read_u32_index(r5_core->np, "power-domains", 1, &r5_core->pm_domain_id); base-commit: 90d6db82626be5e5fe085f4f58c49a080c420fa6 -- 2.25.1 [View Less]

2 years, 3 months

1
0
0 0

OpenAMP System Reference WG

by Chan King Choy, Nathalie

First meeting of 2023. Agenda: * Bill: What are the 2023 HPP objectives? * All: Discuss brainstorm list<https://docs.google.com/document/d/19Bpss2PHw8xavpviWZ1vu45hxrIbBG8mSSgKhrE…> on what makes sense to work on next * Nathalie: Scheduling 2023 meeting series [https://st2.zoom.us/static/6.3.10219/image/new/ZoomLogo_110_25.png]<https://zoom.us/> Hi there, Nathalie Chan King Choy is inviting you to a scheduled Zoom meeting. Join Zoom Meeting<https://xilinx.zoom.us/… [View More]

2 years, 4 months

1
0
0 0

2022-12-14 OpenAMP System Reference notes and action items

by Chan King Choy, Nathalie

Hi all, Notes from today's call are posted at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref… Link to the google doc with brainstorm ideas for 2023 is below, so feel free to add to it as you get ideas. Action items * @Chan King Choy, Nathalie<mailto:nathalie.chan-king-choy@amd.com>: Ask Linaro Events what attendee info is possible to share with us, if we are interested in making contact * (DONE) Nathalie, Tanmay: Check if YouTube comments are … [View More]

2 years, 4 months

1
0
0 0

Agenda for 2022-12-14 OpenAMP System Reference call

by Chan King Choy, Nathalie

Hi all, Initial proposed topics for tomorrow's OpenAMP System Reference call: * Key learnings / retrospective on Tuesday's webinar * Next steps for System Reference WG * Call frequency going forward for System Reference WG Any other topics, please let us know. Bruce & Mathieu, if you would like to join in the discussion on Key learnings / retrospective on Tuesday's webinar, here's the Zoom link for tomorrow. The call is at 9:30am Pacific / 10:30am Mountain / 12:30pm Eastern … [View More]

2 years, 4 months

2
1
0 0

Webinar merged slide deck - needs update to Try it on your own

by Chan King Choy, Nathalie

Hi Bill, I've merged the slides, removed keep-out rectangles, and put it in our webinar Google Drive folder & also added this link to the top of the Webinar Plan document<https://docs.google.com/document/d/1R-uUgavNI2GCcM133YfgCY5SMLanGT_-DN1nu6R…>: https://docs.google.com/presentation/d/1QE0zyCxm54KoTDuWKS0Xh-mml3SneQjecDg… You can update the Try it on your own slide when you are ready & PDF this for Linaro Events to post prior to the webinar. Thanks & regards, Nathalie

2 years, 4 months

3
4
0 0

Calling for agenda: 2022-12-07 OpenAMP System Reference

by Chan King Choy, Nathalie

Hi all, I made this reminder LinkedIn post on Friday, if you want to like it so it shows up in the feed of your networks: https://www.linkedin.com/feed/update/urn:li:activity:7004598893573267456 I've submitted the webinar video to Linaro events. * We've still got a few open items in the tracking sheet to discuss: https://docs.google.com/spreadsheets/d/1SkQvq34NJBjJM56T6nm9fknJGTHutfV-LJd… (I added the to do items from Bill's email) * Brainstorm some backup questions if Q/A is quiet … [View More]

2 years, 4 months

2
4
0 0

2022-12-07 OpenAMP System Reference notes and action items

by Chan King Choy, Nathalie

Hi all, Notes from today are posted at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref… * Action items: * Tammy: Combine doxygen & markdown docs into same doc folder. OK to rename to "doc" to match libmetal. * Dan to try out demo4 shortcut in demo-lite * Dan to split out demo-lite instructions from build instructions in https://github.com/danmilea/hypervisorless_virtio_zcu102/blob/openamp-demo/… and submit PR so each is linked to show … [View More]

2 years, 4 months

1
0
0 0

OpenAMP System Reference Webinar video - opportunity to review before submission

by Chan King Choy, Nathalie

Hi team, Nice work on all your slides and recordings! Thank you so much for submitting recordings early, so that I could get most of the edits in place before the end-of-quarter craziness that I got swept up in this week. Here is the webinar video combined end-to-end if anyone wants to watch it. I have only watched the components on 2x and the transitions at normal speed. I'll watch the whole thing at normal speed over the weekend. https://drive.google.com/file/d/… [View More]

2 years, 5 months

1
0
0 0

2022-11-29 OpenAMP System Reference recording day notes and action items

by Chan King Choy, Nathalie

Hi all, Notes from today's call are at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref… Action items: * Tomas will try to get hold of Rob from NXP to ask about their membership in OpenAMP * Bill: Add to live slides: slide to mention all the mailing lists (OpenAMP, Linux RP?), Discord link * All: Send Nathalie your head shot or add it to the wrap-up slide https://docs.google.com/presentation/d/1bbdn1irvwdDoW9cR1B9RqVhhCOrK7Lr4JOA… * Nathalie: Add employers to Q/A … [View More]

2 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

Openamp-system-reference