[U-Boot] [PATCH 2/3] spi: Add support for the Aspeed ast2500 SPI controllers

[Cédric Le Goater]

Hello

On 10/10/18 2:02 PM, Cédric Le Goater wrote:
> Hello Boris,
> 
> On 10/10/18 9:32 AM, Boris Brezillon wrote:
>> Hi Cédric,
>>
>> On Wed, 10 Oct 2018 11:46:56 +0530
>> Jagan Teki <jagan at amarulasolutions.com> wrote:
>>
>>> On Mon, Oct 8, 2018 at 11:32 AM Cédric Le Goater <clg at kaod.org> wrote:
>>>>
>>>> On 10/4/18 5:57 PM, Jagan Teki wrote:  
>>>>> On Fri, Sep 28, 2018 at 5:20 PM Cédric Le Goater <clg at kaod.org> wrote:  
>>>>>>
>>>>>> Hello Simon,
>>>>>>
>>>>>>
>>>>>> The Aspeed AST2500 FMC controller can handle SPI flash and NOR flash memory,
>>>>>> and the Aspeed AST2500 SPI Flash Controllers only SPI. If there is some
>>>>>> misunderstanding on this driver, it might come from the fact it is closer
>>>>>> to a SPI-NOR driver like we have in Linux, than a generic SPI driver.
>>>>>> The stm32 SPI driver is somewhat similar.
>>>>>>
>>>>>> Should we move it under drivers/mtd/spi/ maybe ?  
>>>>>
>>>>> Seems with new spi-mem in Linux flash memory driver rely on spi-mem
>>>>> instead of mtd/spi-nor. So I think you can handle this via new
>>>>> spi-mem. have you send any patches to Linux?  
>>>>
>>>> No, not yet. The patchset is sent  :
>>>>
>>>>         https://patchwork.ozlabs.org/cover/933293/
>>>>
>>>> is not using spimem. I was not aware of that change in the spi-nor layer
>>>> at the time. I will take a look.  
>>
>> Indeed, if you have some time to convert the Linux aspeed driver to
>> the spi-mem interface that would be appreciated.
> 
> Yes. That's the plan. I have a series on the way but I will see if I can
> rework a v2 to use spi-mem. 

I took a look at spi-mem and worked on an initial spi-aspeed-smc driver
using the new framework in Linux 5.0.x. It looks good but I have a couple
of questions.  


The first is about performing direct accesses on the AHB window on which 
the flash contents is mapped. 

How do you distinguish a flash read (fast, dual, etc) from a RDSFPD command 
for instance ? Are the drivers expected to check the SPI OP command and 
depending on the target/command redirect to the appropriate address space ?   

Also, Aspeed SPI controllers have a Read Timing Compensation Register which
defines different data input delay cycles depending on SPI clock rates. This 
register is supposed to be tuned when the flash chip characteristics are 
known, after the first bus scan. Is there a way to know that our SPI slave 
is alive and well detected before starting hammering successive reads on it 
to see how it behaves.


I think the U-Boot and Linux driver will be very similar wrt the issues 
above ? 

> Same for the u-boot aspeed spi driver which needs a spi-mem refresh if 
> I understand correctly. 

U-Boot, I haven't looked at yet but I expect the driver to be very similar.

Thanks,

C.