Hi Martin,
On 2019/4/11 1:54, Martin Blumenstingl wrote:
Hi Liang,
On Wed, Apr 10, 2019 at 1:08 PM Liang Yang <liang.yang@xxxxxxxxxxx> wrote:
Hi Martin,
On 2019/4/5 12:30, Martin Blumenstingl wrote:
Hi Liang,
On Fri, Mar 29, 2019 at 8:44 AM Liang Yang <liang.yang@xxxxxxxxxxx> wrote:
Hi Martin,
On 2019/3/29 2:03, Martin Blumenstingl wrote:
Hi Liang,
[......]
I don't think it is caused by a different NAND type, but i have followed
the some test on my GXL platform. we can see the result from the
attachment. By the way, i don't find any information about this on meson
NFC datasheet, so i will ask our VLSI.
Martin, May you reproduce it with the new patch on meson8b platform ? I
need a more clear and easier compared log like gxl.txt. Thanks.
your gxl.txt is great, finally I can also compare my own results with
something that works for you!
in my results (see attachment) the "DATA_IN [256 B, force 8-bit]"
instructions result in a different info buffer output.
does this make any sense to you?
I have asked our VLSI designer for explanation or simulation result by
an e-mail. Thanks.
do you have any update on this?
Sorry. I haven't got reply from VLSI designer yet. We tried to improve
priority yesterday, but i still can't estimate the time. There is no
document or change list showing the difference between m8/b and gxl/axg
serial chips. Now it seems that we can't use command NFC_CMD_N2M on nand
initialization for m8/b chips and use *read byte from NFC fifo register*
instead.
thank you for the status update!
I am trying to understand your suggestion not to use NFC_CMD_N2M:
the documentation (public S922X datasheet from Hardkernel: [0]) states
that P_NAND_BUF (NFC_REG_BUF in the meson_nand driver) can hold up to
four bytes of data. is this the "read byte from NFC FIFO register" you
mentioned?
You are right.take the early meson NFC driver V2 on previous mail as a
reference.
Before I spend time changing the code to use the FIFO register I would
like to wait for an answer from your VLSI designer.
Setting the "correct" info buffer length for NFC_CMD_N2M on the 32-bit
SoCs seems like an easier solution compared to switching to the FIFO
register. Keeping NFC_CMD_N2M on the 32-bit SoCs also allows us to
have only one code-path for 32 and 64 bit SoCs, meaning we don't have
to maintain two separate code-paths for basically the same
functionality (assuming that NFC_CMD_N2M is not completely broken on
the 32-bit SoCs, we just don't know how to use it yet).
All right. I am also waiting for the answer.
Regards
Martin
[0] https://dn.odroid.com/S922X/ODROID-N2/Datasheet/S922X_Public_Datasheet_V0.2.pdf
.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
