On 08/04/2016 07:36 PM, Simon Glass wrote:
Hi Stephen,
On 25 July 2016 at 13:57, Stephen Warren <swar...@wwwdotorg.org> wrote:
On 07/22/2016 08:08 PM, Simon Glass wrote:
Hi Stephen,
On 18 July 2016 at 12:17, Stephen Warren <swar...@wwwdotorg.org> wrote:
From: Stephen Warren <swar...@nvidia.com>
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 <swar...@nvidia.com>
---
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
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?
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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
