Hi all,
Please let us know if you have specific topics for this week's OpenAMP System Reference call. Here's what I have so far:
* Is 1st half of November still looking good for a demo?
* November demo:
* What to convey?
* What should it include?
* What work needs to happen to support that?
* Individual updates
For the November demo discussion, here is an outline that can be helpful (we don't have to use it, but it can be a starting point):
Who is our target audience?
Target audience
e.g. System architect
e.g. RTOS vendor
???
Need/pain/application
How could they benefit from OpenAMP?
What is their alternative to OpenAMP?
Why makes OpenAMP better suited to their needs?
Webinar plan
* What is expected state of audience coming into the webinar?
* What is desired state of the audience after viewing the webinar?
* Call to action:
* What should they do next?
* Why should they do this? (i.e. what's the benefit for them?)
* Top 3 key takeaways
* What are the sections of the webinar? For example:
* Intro (Why OpenAMP slides) + what's in today's demo
* Demo 1: ??
* Demo 2: ??
* CTA:
* Try it out, here's where to find the stuff & how to give feedback
* Get involved, here's how
* Summary of takeaways/Conclusion
Work breakdown
* Getting the webinar scheduled/advertised
* Slides
* Demo 1
* Demo 2
* Demo N
* Repositories
* Documentation
* Any other top level tasks to break down, or better way to categorize the tasks?
Thanks & regards,
Nathalie
Hi all,
Notes from yesterday's call can be found at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref… .
Action items from this call:
* @arnaud.pouliquen@st.com<mailto:arnaud.pouliquen@st.com>: Check if ST has parts w/ hard-wired Ethernet.
* @Bill Mills<mailto:bill.mills@linaro.org>: ask if others in Linaro know more on Zephyr certification project status.
* @Chan King Choy, Nathalie<mailto:nathalie.chan-king-choy@amd.com>: Send email to Board when we should meet again & put social channels on the agenda
* @Milea, Danut Gabriel (Danut)<mailto:Danut.Milea@windriver.com>: The required mods to use UART for R5 are in one of our Zephyr repos. In a DT overlay somewhere. Can check & share.
Best regards,
Nathalie
Hi all,
Calling for agenda items. Here's what I have so far:
* Individual updates
* 7/6 call: Dan will be OOO 7/6 & other US folks might be taking holidays that week due to the long weekend. Options:
* A) Keep it?
* B) Push out the 7/6 call by a week, reconvene on 7/13
* C) Cancel 7/6, reconvene on 7/20
Thanks & regards,
Nathalie
On 6/9/22 10:33 AM, Rob Herring wrote:
> On Tue, Jun 07, 2022 at 10:32:48AM -0700, Tanmay Shah wrote:
>> Hi Rob,
>>
>> Ping for reviews.
> No need to ping me. You can check status of your patch here:
>
> https://patchwork.ozlabs.org/project/devicetree-bindings/list/
>
> If it is listed, Krzysztof or I will get to it.
Thanks for the link. This is good to know.
> Rob
HI Rob,
Thanks for reviews. Please find my comments below.
On 6/9/22 10:41 AM, Rob Herring wrote:
> On Fri, Jun 03, 2022 at 08:33:13AM +0200, Peter Korsgaard wrote:
>>>>>>> "Tanmay" == Tanmay Shah <tanmay.shah(a)xilinx.com> writes:
>> Hi,
>>
>> > Xilinx ZynqMP platform has dual-core ARM Cortex R5 Realtime Processing
>> > Unit(RPU) subsystem. This patch adds dt-bindings for RPU subsystem
>> > (cluster).
>>
>> > Signed-off-by: Tanmay Shah <tanmay.shah(a)xilinx.com>
>> > ---
>>
>> > Changes in v8:
>> > - Add 'items:' for sram property
>>
>> > Changes in v7:
>> > - Add minItems in sram property
>>
>> > Changes in v6:
>> > - Add maxItems to sram and memory-region property
>>
>> > Changes in v5:
>> > - Add constraints of the possible values of xlnx,cluster-mode property
>> > - fix description of power-domains property for r5 core
>> > - Remove reg, address-cells and size-cells properties as it is not required
>> > - Fix description of mboxes property
>> > - Add description of each memory-region and remove old .txt binding link
>> > reference in the description
>>
>> > Changes in v4:
>> > - Add memory-region, mboxes and mbox-names properties in example
>>
>> > Changes in v3:
>> > - None
>>
>> > .../bindings/remoteproc/xlnx,r5f-rproc.yaml | 130 ++++++++++++++++++
>> > include/dt-bindings/power/xlnx-zynqmp-power.h | 6 +
>> > 2 files changed, 138 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/remoteproc/xlnx,r5f-rproc.yaml
>>
>> > diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,r5f-rproc.yaml
>> > new file mode 100644
>> > index 000000000000..adfe05ff157a
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,r5f-rproc.yaml
>> > @@ -0,0 +1,132 @@
>> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> > +%YAML 1.2
>> > +---
>> > +$id: http://devicetree.org/schemas/remoteproc/xlnx,r5f-rproc.yaml#
>> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> > +
>> > +title: Xilinx R5F processor subsystem
>> > +
>> > +maintainers:
>> > + - Ben Levinsky <ben.levinsky(a)xilinx.com>
>> > + - Tanmay Shah <tanmay.shah(a)xilinx.com>
>> > +
>> > +description: |
>> > + The Xilinx platforms include a pair of Cortex-R5F processors (RPU) for
>> > + real-time processing based on the Cortex-R5F processor core from ARM.
>> > + The Cortex-R5F processor implements the Arm v7-R architecture and includes a
>> > + floating-point unit that implements the Arm VFPv3 instruction set.
>> > +
>> > +properties:
>> > + compatible:
>> > + const: xlnx,zynqmp-r5fss
>> > +
>> > + xlnx,cluster-mode:
>> > + $ref: /schemas/types.yaml#/definitions/uint32
>> > + enum: [0, 1, 2]
>>
>> A textual mode ("dual", "lock-step", "single") would be more readable.
>>
>>
>> > + description: |
>> > + The RPU MPCore can operate in split mode(Dual-processor performance), Safety
>>
>> space missing before "(Dual-processor"
>>
>>
>> > + lock-step mode(Both RPU cores execute the same code in lock-step,
>> > + clock-for-clock) or Single CPU mode (RPU core 0 can be held in reset while
>>
>> "can be" sounds a bit weak, perhaps "is"
>>
>>
>> > + core 1 runs normally). The processor does not support dynamic configuration.
>> > + Switching between modes is only permitted immediately after a processor reset.
>> > + If set to 1 then lockstep mode and if 0 then split mode.
>> > + If set to 2 then single CPU mode. When not defined, default will be lockstep mode.
>>
>> This looks a bit confusing. If you decide to stick to the numerical
>> modes, then at least list them in numerical order, E.G.:
>>
>> 0: split
>> 1: lockstep
>> 2: single
I think the description is fine. for readability I can just add
numerical order as above.
> The bigger issue has been multiple Cortex-R5 bindings all doing their
> own thing for this feature which is not vendor specific (except TI has
> their own extra mode or something). How TCMs are described is the
> other issue. I've just stopped caring because no one listens.
Values used for cluster-mode property for xlnx platform is same as ti's
cluster mode property.
0: split, 1: lockstep and 2: single-cpu mode. It is matching with
ti,k3-r5 bindings.
However, default value for some of the ti platforms are different.
xlnx platforms have single-cpu mode as well.
It will take some time to design system-dt spec for TCM.
So, for now I use hard-code values of TCM from driver.
TCM bindings for linux will be posted once system-dt spec is accepted.
Meanwhile we would like to upstream rest of the bindings and driver.
>
>>> +
>> > +patternProperties:
>> > + "^r5f-[a-f0-9]+$":
>> > + type: object
>> > + description: |
>> > + The RPU is located in the Low Power Domain of the Processor Subsystem.
>> > + Each processor includes separate L1 instruction and data caches and
>> > + tightly coupled memories (TCM). System memory is cacheable, but the TCM
>> > + memory space is non-cacheable.
>> > +
>> > + Each RPU contains one 64KB memory and two 32KB memories that
>> > + are accessed via the TCM A and B port interfaces, for a total of 128KB
>> > + per processor. In lock-step mode, the processor has access to 256KB of
>> > + TCM memory.
>> > +
>> > + properties:
>> > + compatible:
>> > + const: xlnx,zynqmp-r5f
>> > +
>> > + power-domains:
>> > + description: RPU core PM domain specifier
>> > + maxItems: 1
>>
>> A bit more detail would be good, E.G. something like arm/cpus.yaml does:
>>
>> List of phandles and PM domain specifiers, as defined by bindings of the
>> PM domain provider (see also ../power_domain.txt).
>>
>> And the phandle-array ref.
> Both suggestions are wrong. We don't need common properties re-described
> by every user. They already have a type definition too, so we don't need
> to repeat phandle-array ref either.
>
> The existing description is not needed either as it doesn't provide any
> information specific to this binding. You only need to describe each
> entry when there is more than 1 entry because we need to know what each
> entry is and the order.
I will remove current description as well.
Thanks.
>
>>> +
>> > + mboxes:
>> > + minItems: 1
>> > + items:
>> > + - description: mailbox channel to send data to RPU
>> > + - description: mailbox channel to receive data from RPU
>> > +
>> > + mbox-names:
>> > + minItems: 1
>> > + items:
>> > + - const: tx
>> > + - const: rx
>>
>> And here as well for mailbox/mailbox.txt
> Nope!
>
>>
>> > +
>> > + sram:
>> > + $ref: /schemas/types.yaml#/definitions/phandle-array
>> > + minItems: 1
>> > + maxItems: 8
>> > + items:
>> > + maxItems: 1
>> > + description: |
>> > + phandles to one or more reserved on-chip SRAM regions. Other than TCM,
>> > + the RPU can execute instructions and access data from, the OCM memory,
>> > + the main DDR memory, and other system memories.
>>
>> Drop the comma after "from"
>>
>>
>> > +
>> > + The regions should be defined as child nodes of the respective SRAM
>> > + node, and should be defined as per the generic bindings in,
>>
>> Drop the comma after "in"
>>
>>
>> > + Documentation/devicetree/bindings/sram/sram.yaml
>> > +
>> > + memory-region:
>> > + description: |
>> > + List of phandles to the reserved memory regions associated with the
>> > + remoteproc device. This is variable and describes the memories shared with
>> > + the remote processor (e.g. remoteproc firmware and carveouts, rpmsg
>> > + vrings, ...). This reserved memory region will be allocated on DDR memory.
>>
>> s/on DDR/in DDR/
>>
>> > + minItems: 1
>> > + maxItems: 8
>> > + items:
>> > + - description: region used for RPU firmware image section
>> > + - description: vdev buffer
>> > + - description: vring0
>> > + - description: vring1
>> > + additionalItems: true
>> > +
>> > + required:
>> > + - compatible
>> > + - power-domains
>> > +
>> > + unevaluatedProperties: false
>> > +
>> > +required:
>> > + - compatible
>> > +
>> > +additionalProperties: false
>> > +
>> > +examples:
>> > + - |
>> > + r5fss: r5fss {
>> > + compatible = "xlnx,zynqmp-r5fss";
>> > + xlnx,cluster-mode = <1>;
>> > +
>> > + r5f-0 {
>> > + compatible = "xlnx,zynqmp-r5f";
>> > + power-domains = <&zynqmp_firmware 0x7>;
>> > + memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>, <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
>> > + mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
>> > + mbox-names = "tx", "rx";
>> > + };
>> > +
>> > + r5f-1 {
>> > + compatible = "xlnx,zynqmp-r5f";
>> > + power-domains = <&zynqmp_firmware 0x8>;
>> > + memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>, <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
>> > + mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
>> > + mbox-names = "tx", "rx";
>> > + };
>> > + };
>> > +...
>> > diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h b/include/dt-bindings/power/xlnx-zynqmp-power.h
>> > index 0d9a412fd5e0..618024cbb20d 100644
>> > --- a/include/dt-bindings/power/xlnx-zynqmp-power.h
>> > +++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
>> > @@ -6,6 +6,12 @@
>> > #ifndef _DT_BINDINGS_ZYNQMP_POWER_H
>> > #define _DT_BINDINGS_ZYNQMP_POWER_H
>>
>> > +#define PD_RPU_0 7
>> > +#define PD_RPU_1 8
>> > +#define PD_R5_0_ATCM 15
>> > +#define PD_R5_0_BTCM 16
>> > +#define PD_R5_1_ATCM 17
>> > +#define PD_R5_1_BTCM 18
>> > #define PD_USB_0 22
>> > #define PD_USB_1 23
>> > #define PD_TTC_0 24
>> > --
>>
>> > 2.25.1
>>
>>
>> --
>> Bye, Peter Korsgaard
>>
This patch series adds bindings document for RPU subsystem found on Xilinx
ZynqMP platforms. It also adds device nodes and driver to enable RPU
subsystem in split mode and lockstep mode.
Xilinx ZynqMP platform contains Remote Processing Unit(RPU). RPU subsystem
contains two arm cortex r5f cores. RPU subsystem can be configured in
split mode, lockstep mode and single-cpu mode.
RPU subsystem also contains 4 Tightly Coupled Memory(TCM) banks.
In lockstep mode, all 4 banks are combined and total of 256KB memory is
made available to r5 core0. In split mode, both cores can access two
TCM banks i.e. 128 KB.
RPU can also fetch data and execute instructions from DDR memory along with
TCM memory.
---
Changes in v8:
- add 'items:' for sram property
Changes in v7:
- Add minItems in sram property
Changes in v6:
- Add maxItems to sram and memory-region property
Changes in v5:
- Add constraints of the possible values of xlnx,cluster-mode property
- fix description of power-domains property for r5 core
- Remove reg, address-cells and size-cells properties as it is not required
- Fix description of mboxes property
- Add description of each memory-region and remove old .txt binding link
reference in the description
- Remove optional reg property from r5fss node
- Move r5fss node out of axi node
Changes in v4:
- Add memory-region, mboxes and mbox-names properties in dt-bindings example
- Add reserved memory region node and use it in Xilinx dt RPU subsystem node
- Remove redundant header files
- use dev_err_probe() to report errors during probe
- Fix missing check on error code returned by zynqmp_r5_add_rproc_core()
- Fix memory leaks all over the driver when resource allocation fails for any core
- make cluster mode check only at one place
- remove redundant initialization of variable
- remove redundant use of of_node_put()
- Fix Comment format problem
- Assign offset of zynqmp_tcm_banks instead of duplicating it
- Add tcm and memory regions rproc carveouts during prepare instead of parse_fw
- Remove rproc_mem_entry object from r5_core
- Use put_device() and rproc_del() APIs to fix memory leaks
- Replace pr_* with dev_*. This was missed in v3, fix now.
- Use "GPL" instead of "GPL v2" in MODULE_LICENSE macro. This was reported by checkpatch script.
Changes in v3:
- Fix checkpatch script indentation warning
- Remove unused variable from xilinx remoteproc driver
- use C style comments, i.e /*...*/
- Remove redundant debug information which can be derived using /proc/device-tree
- Fix multiline comment format
- s/"final fot TCM"/"final for TCM"
- Function devm_kzalloc() does not return an code on error, just NULL.
Remove redundant error check for this function throughout the driver.
- Fix RPU mode configuration and add documentation accordingly
- Get rid of the indentations to match function documentation style with rest of the driver
- Fix memory leak by only using r5_rproc->priv and not replace it with new instance
- Use 'i' for the outer loop and 'j' for the inner one as per convention
- Remove redundant error and NULL checks throughout the driver
- Use devm_kcalloc() when more than one element is required
- Add memory-regions carveouts during driver probe instead of parse_fw call
This removes redundant copy of reserved_mem object in r5_core structure.
- Fix memory leak by using of_node_put()
- Fix indentation of tcm_mem_map function args
- Remove redundant init of variables
- Initialize tcm bank size variable for lockstep mode
- Replace u32 with phys_addr_t for variable stroing memory bank address
- Add documentation of TCM behavior in lockstep mode
- Use dev_get_drvdata instead of platform driver API
- Remove info level messages
- Fix checkpatch.pl warnings
- Add documentation for the Xilinx r5f platform to understand driver design
Changes in v2:
- Remove proprietary copyright footer from cover letter
Ben Levinsky (3):
firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
firmware: xilinx: Add shutdown/wakeup APIs
firmware: xilinx: Add RPU configuration APIs
Tanmay Shah (3):
dt-bindings: remoteproc: Add Xilinx RPU subsystem bindings
arm64: dts: xilinx: zynqmp: Add RPU subsystem device node
drivers: remoteproc: Add Xilinx r5 remoteproc driver
.../bindings/remoteproc/xlnx,r5f-rproc.yaml | 132 +++
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 33 +
drivers/firmware/xilinx/zynqmp.c | 97 ++
drivers/remoteproc/Kconfig | 12 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/xlnx_r5_remoteproc.c | 1045 +++++++++++++++++
include/dt-bindings/power/xlnx-zynqmp-power.h | 6 +
include/linux/firmware/xlnx-zynqmp.h | 60 +
8 files changed, 1386 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/xlnx,r5f-rproc.yaml
create mode 100644 drivers/remoteproc/xlnx_r5_remoteproc.c
base-commit: 01a1a0c8d456b11f2f6b9b822414481beaa44d6f
--
2.25.1