Hi Stephen, On 5 August 2016 at 10:04, Stephen Warren <swar...@wwwdotorg.org> wrote: > 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.
I think both could be driver-to-driver, but I'm going to settle for what you are offering. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
