On 07/02/22 06:13PM, Cédric Le Goater wrote:

Hello,

On 1/24/22 21:37, Pratyush Yadav wrote:

quoted

On 24/01/22 07:34PM, Cédric Le Goater wrote:

quoted

quoted

quoted

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?

Last time I looked, we lacked some post_init handler to setup a slave:
configure the registers defining the AHB windows for each flash
slave and perform the read timing calibration. calibration should
only be done once.

See how the aspeed_spi_flash_init() routine doing the calibration
is hooked up under aspeed_spi_claim_bus() in the u-boot driver :

My patch series should provide a hook for doing the calibration _after_
the flash is initialized.

You can also use the .dirmap_create handler. The flash device has
been scanned when called and the size is available in the spi-mem
dirmap descriptor.

I feel uncomfortable doing that since the API does not actually make 
this guarantee. Who knows if a future change will violate that 
assumption. That is why I added a new API call to explicitly mark the 
flash as ready. I suppose you can get the op from the .dirmap_create 
handler, but I guess we can debate that over the patches.

I reworked the current Aspeed driver with this approach and it
seems sufficient for read calibration.

Thanks,

C.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.