[PATCH] mtd: aspeed-smc: improve probe resilience
p.yadav at ti.com
Tue Jan 25 02:36:44 AEDT 2022
On 23/01/22 11:44PM, Cédric Le Goater wrote:
> > > I had an offline discussion with someone who knew more history on this driver.
> > > My understanding is that the linux-aspeed team is aware of this being deprecated
> > > but that there was some missing support for interface training that nobody has
> > > gotten around to write? If that is the case this really isn't even a "simple"
> > > port to a new API at this point.
> > Unless the controller needs some unique feature (I don't think it does
> > on a quick glance), the conversion should not be too difficult. For any
> > experienced developer, even if they are unfamiliar with the SPI MEM API,
> > I don't think it should take more than 2-3 days to do the conversion.
> > The code to program the registers would stay the same, all that needs to
> > change is the API through which it is accessed.
> Writing a spimem driver is not a problem, I think people have done
> that in house. Aspeed has one for AST2600. We have one for u-boot
> I wrote sometime ago. I even have one for Linux but training comes
> with ugly hacks to fit in the current stack.
> All Aspeed SoCs need training and that has been the problem for the
> last 4 years or so because we can not do training without knowing
> a minimum about the flash being trained :/ The previous framework
> offered a way to do a first scan and tune the delay settings
> afterwards. It worked pretty well on AST2400, AST2500 and AST2600
> even if more complex.
> One alternative was to include the setting in the DT but the flash
> modules are not always soldered on the boards, at least on OpenPOWER
> systems which have sockets for them. The board are large, the wires
> long, the need is real, some chips freak out if not tuned correctly.
> spimem needs an extension I think. Sorry I have not been able to
> push that forward. Lack of time and other tasks to address on the
> host side of the machine. This is really a software problem, we
> have the HW procedures ready. If a spimem expert could get involved
> to make a few proposals, I would be happy to help and do some testing.
> QEMU models are good enough for the software part. We can do the
> training validation on real HW when ready.
What information about the flash do you need for this training? I
proposed a patch series  some time ago trying to implement training
for TI SoCs. It did not get merged but I do intend to respin it and get
it through. Would this API work for your tuning as well?
Also, I am curious how your training works. What data do you read for
training delays? Where is it stored? In our case we need to flash a
known pattern at some location (which is passed in via DT). Do you need
to run it for every read transaction or just once after the flash is
Texas Instruments Inc.
More information about the Linux-aspeed