Re: [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers

[Jeremy Kerr <jk@codeconstruct.com.au>]

Hi Greg,

> FWIW, we did raise greybus as an approach to various HW vendors; I
> assume there were reasons behind OBMF-ICP, and assume some prior-art
> assesment was involved, but I don't have specifics for those reasons.
>
> HW peeps: This would be an excellent opportunity for elaboration on the
> motivation there, either for LSTP or OBMF-OCP.

I have been doing some asking around, and a few items came up around
motivations for OBMC-ICP over Greybus. My motivation here is entirely
around OBMF-ICP; the NVIDIA contributions for LSTP somewhat comes under
this, and so we're working on composing a unified solution.

Collating some of those items here:

As a bit of background, the typical use case for OBMF-ICP is for
platform pre-boot environments, with limitations in capabilities of both
the hardware and software stack. Microcontroller and mask-ROM
implementations of either side of the protocol are potential targets.

This leads to the structure of OBMF-ICP being intentionally
light-weight; the channel configuration (ie, definition of the
encapsulated devices) is static, and the channel-level messaging is kept
simple, mainly through a requirement of only one message in flight per
channel.

[Greg, this is related to one of your points around why not use a
multi-function USB device for individual, separate devices: the typical
device-side hardware does not have support for enough USB endpoints to
do so. Like greybus, the intention is to be able to support multiple
downstream peripherals without constraints from USB hardware on existing
SoC devices]

There are a few design points that lead to the preference for OBMF-ICP:

The front-loaded configuration mechanism means less state to manage on
both sides of the protocol; the channel set and channel-specific
parameters (like individual GPIO descriptors and flash geometry) being
stable over the lifetime of the device means simpler core protocol
support and channel driver implementations.

The simpler channel communication protocol is better suited to
lower-complexity interfaces that are needed for the pre-boot
environments (GPIO control, uart, IPMI, flash access) than the greybus
targets for mobile device runtime, with higher-bandwidth communication
requirements (camera, audio, display). For example, typical platform
management functions generally involve a lot of short i2c operations -
ICP messages for these are around half the length of greybus
equivalents.

For the platform-boot use-cases, we would need to provide a bunch of new
channel definitions for greybus. This certainly isn't a showstopper in
itself, but the specification does not appear to be in active
development; last change was 10 years ago, and the spec repository has
since been archived as far as I can tell (and so is read-only).

With OBMF-ICP's super-minimal core protocol, and the use-case
appropriate channels, seems like a suitable approach to me.

The USB-IF has a class ID allocated for OBMF-ICP interface descriptors,
with the intention that we have multiple vendor implementations of the
common protocol; we would like Linux to be one of those.

Cheers,


Jeremy