Hello Tokunori-san,
On 08.03.22 17:13, Tokunori Ikegami wrote:
Hi Ahmad-san,I see that, but I am not sure it's the correct thing to do on the S29GL064N,
On 2022/03/08 18:44, Ahmad Fatoum wrote:
Hello Tokunori,Thank you so much for your test.
On 06.03.22 16:49, Tokunori Ikegami wrote:
Hi,Works good.
On 2022/03/04 20:11, Ahmad Fatoum wrote:
Hello Tokunori-san,Thanks for your support.
On 20.02.22 13:22, Tokunori Ikegami wrote:
Hi Ahmad-san,I had a similar patch locally as well at first. I just tested yours
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().
and I can't reproduce the issue.
Sorry if possible could you please retest the attached the patch again since this fixed the version 1 patch maintainer review comments?
Tested-by: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
The change to check 0xFF can be limited for the S29GL064N chip do you have any comment about this?The original version has less room for surprise as it restores previouslyI see.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.That it works for me could be because of Hi-Z 0xff, which is why
decided against it.
Noted but still I am thinking the version 2 patch to check 0xff seems better than to use chip_ready() so let me consider this again later.I've be ok with v1 then. Restores working behavior for me and shouldn't break others.As far as I checked still both chip_good() and chip_ready() seem correct but still the root cause is unknown.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.What exactly in the datasheet makes you believe chip_good is not appropriate?What seems to work for me is checking if chip_good or chip_readySorry I am not sure about this.
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...)
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.
Anyway let me recheck the data sheet details as just checked it again quickly but needed more investigation to understand.
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().
working behavior. Assuming 0xFF to be good without backing from documentation
is more risky IMO.
even if it seems to work. In absence of definitive information from the vendor,
I'd prefer we just restore behavior as it was before, i.e. using chip_ready
instead of chip_good for S29GL064N. This is the way of least surprise.
Just attached the patch changed as so and thinking to send the patch as version 3 to the maintainer if you are okay.
Regards,
Ikegami
Thanks for your continued support,
Ahmad
Regards,
Ikegami
Cheers and thanks again,
Ahmad
Regards,
Ikegami
Regards,
Ikegami
Cheers,
Ahmad