[U-Boot] [PATCH] ARM: tegra: add IVC protocol implementation

[Stephen Warren]

On 08/04/2016 07:36 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 25 July 2016 at 13:57, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/22/2016 08:08 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 18 July 2016 at 12:17, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>
>>>> From: Stephen Warren <swarren at 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 <swarren at 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.