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

[Simon Glass]

Hi Stephen,

On 5 August 2016 at 10:04, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 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.

I think both could be driver-to-driver, but I'm going to settle for
what you are offering.

Regards,
Simon