Aspeed SPI driver upstreaming

Cédric Le Goater clg at
Mon Jan 13 19:02:55 AEDT 2020

On 1/9/20 5:43 PM, Patrick Williams wrote:
> Thanks for the reply Cédric.
> On Tue, Jan 07, 2020 at 09:34:03AM +0100, Cédric Le Goater wrote:
>> Regarding the SMC driver, the maintainers are requesting a rewrite 
>> of the driver using the spimem layer, but we lack handlers to do 
>> the read training and compute the timing register value.
>> This is the first thing to address on the todo list. When available,
>> it shouldn't take too long to upstream the driver. Some more info 
>> here :
> It looks like this patch set is still the MTD-only implementation, which
> is useful for SPI-NOR chips but not useful for non-flash devices such as
> TPMs.  Is there any work or thought into how we could do a generic SPI
> controller and then layer the MTD above it?

Not on my side. I always worked with flash support in mind.

> We have some system designs where we have both a NOR device and a TPM on
> the same SPI bus.  What we're currently doing is using the
> (non-upstream) aspeed-spi driver which lets us use both the TPM and
> MTD/SPI-NOR driver, but since it doesn't have the calibration routines
> the SPI-NOR runs at a slower speed than optimal.
> I'd really like to get a generic SPI controller driver upstreamed, even if it
> doesn't have the calibration (the SPI-NOR device in this case is not as
> performance critical as the BMC's own NOR devices).  Is there any path
> to combining the features of the aspeed-smc and aspeed-spi into a single
> driver, or do you think we should start with them as separate and get
> aspeed-spi upstreamed as an alternative to aspeed-smc?

Yes, we should and this is requested by the MTD community which wants
to deprecate SPI-NOR.

> Also, do you have any soft timeline on the follow-ups to this patch set?

AST2600 was done on my spare time this year. I have been working on the 
other side of the system (PowerPC XIVE) these last two/three years and 
should continue to do so.

If a new Aspeed flash driver should emerge, I think some else should take 
ownership. It will be better for maintenance



More information about the openbmc mailing list