Hi Cédric, On 25/01/19 11:30 PM, Boris Brezillon wrote: > +Vignesh > [...] >> 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. >
Right, Cadence QSPI/OSPI needs PHY DLL values to be tuned for operating at higher frequencies. So idea is to use READID to read flash ID at lowest speed and use that as golden reference for tuning/link training at higher frequencies. I am guessing Aspeed SPI controller has similar need. Here is the discussion that Boris was talking about: https://lkml.org/lkml/2018/10/4/468 I haven't been able to get to implement his suggestions yet, but I think idea is generic enough. >> >> >> I think the U-Boot and Linux driver will be very similar wrt the issues >> above ? > I have submitted patches[1] to sync SPI NOR framework from kernel to U-Boot. Once that's merged then Aspeed SPI can make use of spi-mem interface in U-Boot as well. [1] https://patchwork.ozlabs.org/cover/1017335/ -- Regards Vignesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
