ARM: tegra: add IVC protocol implementation
Subsystems (3)
PATCH 1/1 ARM: tegra: add IVC protocol implementation
From: Stephen Warren <[email protected]>
IVC (Inter-VM Communication) protocol is a Tegra-specific IPC (Inter Processor Communication) framework. Within the context of U-Boot, it is typically used for communication between the main CPU and various auxiliary processors. In particular, it will be used to communicate with the BPMP (Boot and Power Management Processor) on Tegra186 in order to manipulate clocks and reset signals.
---
This depends on "ARM: tegra: unify Tegra186 Makefile a bit" (which I just sent) purely for a tiny bit of diff context in the Makefile. Otherwise, it's entirely independent.
arch/arm/include/asm/arch-tegra/ivc.h | 179 +++++++++++ arch/arm/mach-tegra/Kconfig | 9 + arch/arm/mach-tegra/Makefile | 1 + arch/arm/mach-tegra/ivc.c | 553 ++++++++++++++++++++++++++++++++++ 4 files changed, 742 insertions(+) create mode 100644 arch/arm/include/asm/arch-tegra/ivc.h create mode 100644 arch/arm/mach-tegra/ivc.c
arch/arm/include/asm/arch-tegra/ivc.h new file +179 -0
@@ -0,0 +1,179 @@ +/* +* Copyright (c) 2016, NVIDIA CORPORATION. +* +* SPDX-License-Identifier: GPL-2.0 +*/ + +#ifndef _ASM_ARCH_TEGRA_IVC_H +#define _ASM_ARCH_TEGRA_IVC_H + +#include <common.h> + +/* +* Tegra IVC is a communication protocol that transfers fixed-size frames +* bi-directionally and in-order between the local CPU and some remote entity. +* Communication is via a statically sized and allocated buffer in shared +* memory and a notification mechanism. +* +* This API handles all aspects of the shared memory buffer's metadata, and +* leaves all aspects of the frame content to the calling code; frames +* typically contain some higher-level protocol. The notification mechanism is +* also handled externally to this API, since it can vary from instance to +* instance. +* +* The client model is to first find some free (for TX) or filled (for RX) +* frame, process that frame's memory buffer (fill or read it), and then +* inform the protocol that the frame has been filled/read, i.e. advance the +* write/read pointer. If the channel is full, there may be no available frames +* to fill/read. In this case, client code may either poll for an available +* frame, or wait for the remote entity to send a notification to the local +* CPU. +*/ + +/** +* struct tegra_ivc - In-memory shared memory layout. +* +* This is described in detail in ivc.c. +*/ +struct tegra_ivc_channel_header ; + +/** +* struct tegra_ivc - Software state of an IVC channel. +* +* This state is internal to the IVC code and should not be accessed directly +* by clients. It is public solely so clients can allocate storage for the +* structure. +*/ +struct tegra_ivc { +/** +* rx_channel - Pointer to the shared memory region used to receive +* messages from the remote entity. +*/ +struct tegra_ivc_channel_header *rx_channel; +/** +* tx_channel - Pointer to the shared memory region used to send +* messages to the remote entity. +*/ +struct tegra_ivc_channel_header *tx_channel; +/** +* r_pos - The position in list of frames in rx_channel that we are +* reading from. +*/ +uint32_t r_pos; +/** +* w_pos - The position in list of frames in tx_channel that we are +* writing to. +*/ +uint32_t w_pos; +/** +* nframes - The number of frames allocated (in each direction) in +* shared memory. +*/ +uint32_t nframes; +/** +* frame_size - The size of each frame in shared memory. +*/ +uint32_t frame_size; +/** +* notify - Function to call to notify the remote processor of a +* change in channel state. +*/ +void (*notify)(struct tegra_ivc *); +}; + +/** +* tegra_ivc_read_get_next_frame - Locate the next frame to receive. +* +* Locate the next frame to be received/processed, return the address of the +* frame, and do not remove it from the queue. Repeated calls to this function +* will return the same address until tegra_ivc_read_advance() is called. +* +* @ivc The IVC channel. +* @frame Pointer to be filled with the address of the frame to receive. +* +* @return 0 if a frame is available, else a negative error code. +*/ +int tegra_ivc_read_get_next_frame (struct tegra_ivc *ivc,void **frame); + +/** +* tegra_ivc_read_advance - Advance the read queue. +* +* Inform the protocol and remote entity that the frame returned by +* tegra_ivc_read_get_next_frame() has been processed. The remote end may then +* re-use it to transmit further data. Subsequent to this function returning, +* tegra_ivc_read_get_next_frame() will return a different frame. +* +* @ivc The IVC channel. +* +* @return 0 if OK, else a negative error code. +*/ +int tegra_ivc_read_advance (struct tegra_ivc *ivc); + +/** +* tegra_ivc_write_get_next_frame - Locate the next frame to fill for transmit. +* +* Locate the next frame to be filled for transmit, return the address of the +* frame, and do not add it to the queue. Repeated calls to this function +* will return the same address until tegra_ivc_read_advance() is called. +* +* @ivc The IVC channel. +* @frame Pointer to be filled with the address of the frame to fill. +* +* @return 0 if a frame is available, else a negative error code. +*/ +int tegra_ivc_write_get_next_frame (struct tegra_ivc *ivc,void **frame); + +/** +* tegra_ivc_write_advance - Advance the write queue. +* +* Inform the protocol and remote entity that the frame returned by +* tegra_ivc_write_get_next_frame() has been filled and should be transmitted. +* The remote end may then read data from it. Subsequent to this function +* returning, tegra_ivc_write_get_next_frame() will return a different frame. +* +* @ivc The IVC channel. +* +* @return 0 if OK, else a negative error code. +*/ +int tegra_ivc_write_advance (struct tegra_ivc *ivc); + +/** +* tegra_ivc_channel_notified - handle internal messages +* +* This function must be called following every notification. +* +* @ivc The IVC channel. +* +* @return 0 if the channel is ready for communication, or -EAGAIN if a +* channel reset is in progress. +*/ +int tegra_ivc_channel_notified (struct tegra_ivc *ivc); + +/** +* tegra_ivc_channel_reset - initiates a reset of the shared memory state +* +* This function must be called after a channel is initialized but before it +* is used for communication. The channel will be ready for use when a +* subsequent call to notify the remote of the channel reset indicates the +* reset operation is complete. +* +* @ivc The IVC channel. +*/ +void tegra_ivc_channel_reset (struct tegra_ivc *ivc); + +/** +* tegra_ivc_init - Initialize a channel's software state. +* +* @ivc The IVC channel. +* @rx_base Address of the the RX shared memory buffer. +* @tx_base Address of the the TX shared memory buffer. +* @nframes Number of frames in each shared memory buffer. +* @frame_size Size of each frame. +* +* @return 0 if OK, else a negative error code. +*/ +int tegra_ivc_init (struct tegra_ivc *ivc,ulong rx_base,ulong tx_base, +uint32_t nframes,uint32_t frame_size, +void (*notify)(struct tegra_ivc *)); + +#endif
arch/arm/mach-tegra/Kconfig +9 -0
@@ -1,5 +1,13 @@ if TEGRA +config TEGRA_IVC + bool "Tegra IVC protocol" + help + IVC (Inter-VM Communication) protocol is a Tegra-specific IPC + (Inter Processor Communication) framework. Within the context of + U-Boot, it is typically used for communication between the main CPU + and various auxiliary processors. + config TEGRA_COMMON bool "Tegra common options" select DM
@@ -60,6 +68,7 @@ config TEGRA186 select TEGRA186_GPIO select TEGRA_ARMV8_COMMON select TEGRA_HSP + select TEGRA_IVC endchoice
arch/arm/mach-tegra/Makefile +1 -0
@@ -27,6 +27,7 @@ endif obj-$(CONFIG_ARM64) += arm64-mmu.o obj-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o obj-$(CONFIG_TEGRA_GPU) += gpu.o +obj-$(CONFIG_TEGRA_IVC) += ivc.o obj-y += lowlevel_init.o ifndef CONFIG_SPL_BUILD obj-$(CONFIG_ARMV7_PSCI) += psci.o
arch/arm/mach-tegra/ivc.c new file +553 -0
553 lines not on this page · raw message
Signature · 1 line
2.9.2
PATCH 1/1 ARM: tegra: add IVC protocol implementation
Hi Stephen,
Quoted 15 lines · Stephen Warren
From: Stephen Warren <[email protected]>
IVC (Inter-VM Communication) protocol is a Tegra-specific IPC (Inter Processor Communication) framework. Within the context of U-Boot, it is typically used for communication between the main CPU and various auxiliary processors. In particular, it will be used to communicate with the BPMP (Boot and Power Management Processor) on Tegra186 in order to manipulate clocks and reset signals.
Signed-off-by Stephen Warren <[email protected]>---
This depends on "ARM: tegra: unify Tegra186Makefilea bit" (which I just sent) purely for a tiny bit of diff context in theMakefile. Otherwise, it's entirely independent.
Quoted 7 lines
arch/arm/include/asm/arch-tegra/ivc.h | 179 +++++++++++ arch/arm/mach-tegra/Kconfig | 9 + arch/arm/mach-tegra/Makefile | 1 + arch/arm/mach-tegra/ivc.c | 553 ++++++++++++++++++++++++++++++++++ 4 files changed, 742 insertions(+) create mode 100644 arch/arm/include/asm/arch-tegra/ivc.h create mode 100644 arch/arm/mach-tegra/ivc.c
Can this use driver model? It seems different from remoteproc. Maybe mailbox or blk?
Regards,
Simon
PATCH 1/1 ARM: tegra: add IVC protocol implementation
Quoted 26 lines · Simon Glass
Hi Stephen,
Quoted 15 lines · Stephen Warren
From: Stephen Warren <[email protected]>
IVC (Inter-VM Communication) protocol is a Tegra-specific IPC (Inter Processor Communication) framework. Within the context of U-Boot, it is typically used for communication between the main CPU and various auxiliary processors. In particular, it will be used to communicate with the BPMP (Boot and Power Management Processor) on Tegra186 in order to manipulate clocks and reset signals.
Signed-off-by Stephen Warren <[email protected]>---
This depends on "ARM: tegra: unify Tegra186Makefilea bit" (which I just sent) purely for a tiny bit of diff context in theMakefile. Otherwise, it's entirely independent.Quoted 7 lines
arch/arm/include/asm/arch-tegra/ivc.h | 179 +++++++++++ arch/arm/mach-tegra/Kconfig | 9 + arch/arm/mach-tegra/Makefile | 1 + arch/arm/mach-tegra/ivc.c | 553 ++++++++++++++++++++++++++++++++++ 4 files changed, 742 insertions(+)create mode 100644
arch/arm/include/asm/arch-tegra/ivc.hcreate mode 100644arch/arm/mach-tegra/ivc.c
Quoted 2 lines
Can this use driver model? It seems different from remoteproc. Maybe mailbox or blk?
This code is essentially utility/implementation code that will be called from a "DM-enabled" driver. The BPMP driver will be instantiated from DT like any other device, and will "host"/use an IVC channel, hence call the IVC code.
PATCH 1/1 ARM: tegra: add IVC protocol implementation
Hi Stephen,
Quoted 31 lines · Stephen Warren
Quoted 30 lines · Simon Glass
Hi Stephen,
Quoted 24 lines · Stephen Warren
From: Stephen Warren <[email protected]>
IVC (Inter-VM Communication) protocol is a Tegra-specific IPC (Inter Processor Communication) framework. Within the context of U-Boot, it is typically used for communication between the main CPU and various auxiliary processors. In particular, it will be used to communicate with the BPMP (Boot and Power Management Processor) on Tegra186 in order to manipulate clocks and reset signals.
Signed-off-by Stephen Warren <[email protected]>---
This depends on "ARM: tegra: unify Tegra186Makefilea bit" (which I just sent) purely for a tiny bit of diff context in theMakefile. Otherwise, it's entirely independent.arch/arm/include/asm/arch-tegra/ivc.h | 179 +++++++++++ arch/arm/mach-tegra/Kconfig | 9 + arch/arm/mach-tegra/Makefile | 1 + arch/arm/mach-tegra/ivc.c | 553 ++++++++++++++++++++++++++++++++++ 4 files changed, 742 insertions(+)create mode 100644
arch/arm/include/asm/arch-tegra/ivc.hcreate mode 100644arch/arm/mach-tegra/ivc.c
Quoted 9 lines
Quoted 2 lines
Can this use driver model? It seems different from remoteproc. Maybe mailbox or blk?
This code is essentially utility/implementation code that will be called from a "DM-enabled" driver. The BPMP driver will be instantiated from DT like any other device, and will "host"/use an IVC channel, hence call the IVC code.
If you take a look at the cros_ec driver you can see that it has a similar interface. There is a command which allows you to perform various operations on the device. A few drivers sit on top of this device (keyboard, i2c tunnel). This allows debugging and better visibility into the device. What do you think?
Regards,
Simon
PATCH 1/1 ARM: tegra: add IVC protocol implementation
Quoted 43 lines · Simon Glass
Hi Stephen,
Quoted 31 lines · Stephen Warren
Quoted 30 lines · Simon Glass
Hi Stephen,
Quoted 24 lines · Stephen Warren
From: Stephen Warren <[email protected]>
IVC (Inter-VM Communication) protocol is a Tegra-specific IPC (Inter Processor Communication) framework. Within the context of U-Boot, it is typically used for communication between the main CPU and various auxiliary processors. In particular, it will be used to communicate with the BPMP (Boot and Power Management Processor) on Tegra186 in order to manipulate clocks and reset signals.
Signed-off-by Stephen Warren <[email protected]>---
This depends on "ARM: tegra: unify Tegra186Makefilea bit" (which I just sent) purely for a tiny bit of diff context in theMakefile. Otherwise, it's entirely independent.arch/arm/include/asm/arch-tegra/ivc.h | 179 +++++++++++ arch/arm/mach-tegra/Kconfig | 9 + arch/arm/mach-tegra/Makefile | 1 + arch/arm/mach-tegra/ivc.c | 553 ++++++++++++++++++++++++++++++++++ 4 files changed, 742 insertions(+)create mode 100644
arch/arm/include/asm/arch-tegra/ivc.hcreate mode 100644arch/arm/mach-tegra/ivc.cQuoted 8 lines
Quoted 2 lines
Can this use driver model? It seems different from remoteproc. Maybe mailbox or blk?
This code is essentially utility/implementation code that will be called from a "DM-enabled" driver. The BPMP driver will be instantiated from DT like any other device, and will "host"/use an IVC channel, hence call the IVC code.
Quoted 5 lines
If you take a look at the
cros_ecdriver you can see that it has a similar interface. There is a command which allows you to perform various operations on the device. A few drivers sit on top of this device (keyboard, i2c tunnel). This allows debugging and better visibility into the device. What do you think?
There are two related cases we're discussing:
1) (this case) the BPMP driver uses an IPC protocol to communicate with the HW. This is purely utility/library code, all part of the internal BPMP driver implementation. There's no driver-to-driver/device-to-device (in the sense of U-Boot DM drivers/devices) communication/function-calls/...
In this case, I believe we should leave the code as-is. The code happens to be in different files (ivc.v and tegra186_bpmp.c) simply for modularity. However, the code could just as well all have been static functions inside tegra186_bpmp.c. As such, I believe the code structure is just fine as it is.
2) (other case) the BPMP child devices (MFD children in Linux kernel design speak) call into the parent BPMP driver to use this communication path. That is DM driver-to-driver communication. I'll address that in the other thread.
PATCH 1/1 ARM: tegra: add IVC protocol implementation
Hi Stephen,
Quoted 73 lines · Stephen Warren
Quoted 52 lines · Simon Glass
Hi Stephen,
Quoted 42 lines · Stephen Warren
Quoted 35 lines · Simon Glass
Hi Stephen,
Quoted 19 lines · Stephen Warren
From: Stephen Warren <[email protected]>
IVC (Inter-VM Communication) protocol is a Tegra-specific IPC (Inter Processor Communication) framework. Within the context of U-Boot, it is typically used for communication between the main CPU and various auxiliary processors. In particular, it will be used to communicate with
the BPMP (Boot and Power Management Processor) on Tegra186 in order to manipulate clocks and reset signals.Signed-off-by Stephen Warren <[email protected]>---
This depends on "ARM: tegra: unify Tegra186Makefilea bit" (which I just
sent) purely for a tiny bit of diff context in theMakefile. Otherwise, it's entirely independent.Quoted 8 lines
arch/arm/include/asm/arch-tegra/ivc.h | 179 +++++++++++ arch/arm/mach-tegra/Kconfig | 9 + arch/arm/mach-tegra/Makefile | 1 + arch/arm/mach-tegra/ivc.c | 553 ++++++++++++++++++++++++++++++++++ 4 files changed, 742 insertions(+)create mode 100644
arch/arm/include/asm/arch-tegra/ivc.hcreate mode 100644arch/arm/mach-tegra/ivc.cQuoted 2 lines
Can this use driver model? It seems different from remoteproc. Maybe mailbox or blk?
Quoted 4 lines
This code is essentially utility/implementation code that will be called from a "DM-enabled" driver. The BPMP driver will be instantiated from DT like any other device, and will "host"/use an IVC channel, hence call the IVC code.
Quoted 5 lines
If you take a look at the
cros_ecdriver you can see that it has a similar interface. There is a command which allows you to perform various operations on the device. A few drivers sit on top of this device (keyboard, i2c tunnel). This allows debugging and better visibility into the device. What do you think?There are two related cases we're discussing:
1) (this case) the BPMP driver uses an IPC protocol to communicate with the HW. This is purely utility/library code, all part of the internal BPMP driver implementation. There's no driver-to-driver/device-to-device (in the sense of U-Boot DM
drivers/devices) communication/function-calls/...In this case, I believe we should leave the code as-is. The code happens to be in different files (ivc.v and
tegra186_bpmp.c) simply for modularity. However, the code could just as well all have been static functions insidetegra186_bpmp.c. As such, I believe the code structure is just fine as it is.
Quoted 3 lines
2) (other case) the BPMP child devices (MFD children in Linux kernel design speak) call into the parent BPMP driver to use this communication path. That is DM driver-to-driver communication. I'll address that in the other thread.
I think both could be driver-to-driver, but I'm going to settle for what you are offering.
Regards,
Simon