+Vignesh Hi Cédric,
On Fri, 25 Jan 2019 18:28:02 +0100 Cédric Le Goater <c...@kaod.org> wrote: > 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 <ja...@amarulasolutions.com> wrote: > >> > >>> On Mon, Oct 8, 2018 at 11:32 AM Cédric Le Goater <c...@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 <c...@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. Great! > > > The first is about performing direct accesses on the AHB window on which > the flash contents is mapped. We have introduced the dirmap API/interface exactly for this purpose, and the SPI NOR layer will use it in 5.1 (see [1]). > > How do you distinguish a flash read (fast, dual, etc) from a RDSFPD command > for instance ? Why do you need to know the access type? > Are the drivers expected to check the SPI OP command and > depending on the target/command redirect to the appropriate address space ? Definitely not, the SPI MEM layer is supposed to be memory-type agnostic, so you should not guess the operation type based on the opcode. For direct mapping accesses, just implement the ->dirmap_xxx hooks at the controller level and you'll be able to use the feature. > > 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. Vignesh mentioned that a while back (couldn't find the thread where this discussion happened) and I suggested adding a new hook to do this "link training" process where you'd pass a spi_mem_op template + the expected result so that the controller can test different setups until it finds a working one. > > > I think the U-Boot and Linux driver will be very similar wrt the issues > above ? I hope so. Thanks for working on this conversion. Boris [1]https://patchwork.kernel.org/patch/10670755/ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
