Hi Ahmad-san,

Could you please try the version 2 patch attached for the error case?
This version is to check the DQ true data 0xFF by chip_good().
But I am not sure if this works or not since the error is possible to be 
caused by Hi-Z 0xff on floating bus or etc.

On 2022/02/15 3:46, Tokunori Ikegami wrote:

Hi Ahmad-san,

On 2022/02/15 1:22, Ahmad Fatoum wrote:

quoted

Hello Tokunori-san,

On 13.02.22 17:47, Tokunori Ikegami wrote:

quoted

Hi Ahmad-san,

Thanks for your confirmations. Sorry for late to reply.

No worries. I appreciate you taking the time.

quoted

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.fatoum@pengutronix.de>

Thanks for your testing. I have just sent the patch to review.

quoted

quoted

quoted

quoted

quoted

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?

I just mentioned about the actual issue behaviors as not worked 
chip_good() on S29GL964N and not worked chip_ready() on 
MX29GL512FHT2I-11G before etc.
Anyway let me recheck the data sheet details as just checked it again 
quickly but needed more investigation to understand.

As far as I checked still both chip_good() and chip_ready() seem correct 
but still the root cause is unknown.
If as you mentioned the issue was cased by the DQ true data 0xFF I am 
not sure why the read work without any error after the write operation.
Also if the error was caused by the Hi-Z 0xff on floating bus as 
mentioned I am not sure why the read work without any error after the 
write operation with chip_ready().
Sorry anyway the root cause is also unknown when the write operation was 
changed to use chip_good() instead of chip_ready().

Regards,
Ikegami

Regards,
Ikegami

quoted

Cheers,
Ahmad