Re: [PATCH edk2-platforms 1/5] Silicon/SynQuaver/DeviceTree: add node for SPI controller

[Leif Lindholm <leif.lindholm@linaro.org>]

On Mon, Feb 19, 2018 at 08:20:28AM +0000, Ard Biesheuvel wrote:
> >> Not really, since that depends entirely on the OS. We just assert the
> >> presence of a certain IP block at a certain memory offset, and whether
> >> the hardware supports slave mode is left unspecified. Whether the OS
> >> supports slave mode (for this particular IP block) is not a property
> >> of the hardware.
> >
> > I was thinking more along the lines of whether the hardware supports
> > slave mode or not (perhaps as a synthesis option).
> >
> > But, fair enough.
> >
> > If you change SynQuaver -> SynQuacer in 1-2 subject lines, for the series:
> > Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
> >
> 
> Excellent, thanks. However, I am going to respin this and make it much
> more generic:
> 
> - create a separate, generic MezzanineDxe driver (with its own HII menu option)
> - redefine all GPIO, I2C and SPI references in terms of the 96boards
> spec, e.g., GPIO-A, GPIO-B, GPIO-C
>
> That way, you can basically specify how the LS connector has been
> integrated (which I2C/SPI/GPIO), and support anything that the generic
> driver supports.

Excellent - that sounds exactly like what I had been hoping for
initially.

> This is only up to a point, of course. Using the Secure96 RNG in UEFI
> requires a UEFI driver, and some I2C plumbing, but I am trying to make
> that generic as well (which is feasible if the I2C bus on the LS
> connector does not contain anything else that UEFI cares about)

I would hope that's generally the case, and otherwise we'd need to
create some protocol that lets you mux?

I.e., even if we do somethign crazy like support stacking mezzanine
boards, an abstracted mezzanine driver should be able to deal with it
- the only issue would come if there were on-board devices on the same
bus?

/
    Leif