Hello Tokunori-san, On 13.02.22 17:47, Tokunori Ikegami wrote: > Hi Ahmad-san, > > Thanks for your confirmations. Sorry for late to reply.
No worries. I appreciate you taking the time. > Could you please try the patch attached to disable the chip_good() change as > before? > I think this should work for S29GL964N since the chip_ready() is used and > works as mentioned. yes, this resolves my issue: Tested-by: Ahmad Fatoum <a.fat...@pengutronix.de> >>>> Doesn't seem to be a buffered write issue here though as the writes >>>> did work fine before dfeae1073583. Any other ideas? >>> At first I thought the issue is possible to be resolved by using the word >>> write instead of the buffered writes. >>> Now I am thinking to disable the changes dfeae1073583 partially with any >>> condition if possible. >> What seems to work for me is checking if chip_good or chip_ready >> and map_word is equal to 0xFF. I can't justify why this is ok though. >> (Worst case bus is floating at this point of time and Hi-Z is read >> as 0xff on CPU data lines...) > > Sorry I am not sure about this. > I thought the chip_ready() itself is correct as implemented as the data sheet > in the past. > But it did not work correctly so changed to use chip_good() instead as it is > also correct. What exactly in the datasheet makes you believe chip_good is not appropriate? Cheers, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |