[PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support

[YH Chung]

Hi Shulzhenko,
 
> My main concern is trying to understand whether it is completely impossible (or
> introduces too much effort that we'd better not to take) integrating this to SPI
> subsystem.
> 
>  From your reply I understand there are two potential blockers:
> 
> a) Treating eSPI transfers as bus-level transfers (meaning that it will be necessary
> probably making separate driver for OOB/VW/Flash channels as they essentially
> use eSPI as a transport);
> 
> b) Some logic being done by the hardware (i.e. LPC bridge).
> 
> Please confirm my understanding:
> 
> (a) is feasible, but requires many effort to re-define architecture 

I think it may not be a good choice for our hardware, since eSPI has clearly
defined channel semantics and our hardware exposes different subsets of
registers for each channel accordingly. Therefore, it would not fit well with
the general messaging flow required by the SPI subsystem, because we would
have to re-serialize the packets and plumb them through the SPI subsystem to
a consumer that can handle the packet and perform the corresponding register
operations.

> (b) If something is done by the hardware - what is the driver impact? I recall
> eDAF use case when the driver wasn't involved at all - and flash access was fully
> done by the hardware (unless the controller is configured to handle it in SW
> mode).

For hardware mode, I do not think there is much direct driver implementation
impact. If the hardware handles the transaction completely, the driver may
only need to configure the controller during initialization.

Our concern is more about the design semantics. Integrating this into the SPI
subsystem would imply that eSPI packets are treated as low-level SPI-like bus
transfers. However, our hardware handles some channel packets automatically,
so exposing them as normal SPI transfers may not accurately represent how the
hardware operates.