On 8/18/2023 7:33 PM, Miquel Raynal wrote:
Hi Sricharan,
quic_srichara@xxxxxxxxxxx wrote on Fri, 18 Aug 2023 19:21:04 +0530:
Hi Miquel,
On 8/18/2023 7:03 PM, Miquel Raynal wrote:
Hi Sricharan,
quic_srichara@xxxxxxxxxxx wrote on Tue, 8 Aug 2023 10:46:14 +0530:
<..>
With this series applied on linux-next, started seeing the below
messages flooded on console while doing mtd r/w.
"xxx "Opcode not supported: 0"
opcode '0' corresponds to NAND_CMD_READ0. This command inturn was
invoked from qcom_nandc.c driver from below places. For read/write_page
driver does not use the exec ops. Hence these calls just ends up
being -ENOTSUPP and ignored. So removed their invocations.
If this is fine, can this be added to your series ? (will send
git-format patch to add to your cleanup series). So far, tested
mtd raw/block read/writes and all works fine. Will do further tests
as well.
Unless I really don't understand the controller, this is non sense.
nand_read_page_op() is precisely what allows your NAND to perform a
read. Removing this call cannot work.
What you need is a proper ->exec_op() implementation, and repeating
this becomes slightly annoying.
Look at your qcom_op_cmd_mapping, you don't even have a path for reads.
I bet something along:
CMD_READ0:
ret = XXX_OPCODE_READ;
break;
will make it work.
Please fix the driver and test with nandbiterrs -i. If this test works,
it is encouraging. Otherwise it is still broken.
ok understand. Will fix this up.
This is urgent now. The driver in -next is broken, shall I revert
everything or will you test the above fix quickly?
While we are able to reproduce the issue, add path for
CMD_READ0/READ_START for IPQ platforms. All mtd tests including
nandbiterrs works fine. But we are not able to get hold of a SDX
device where we could reproduce the issue to debug. We are working
offline with Manivannan for the SDX remote debug. Will keep you
updated here and if we are not able to solve this on SDX in next
couple of days, only way looks like revert and re-apply it for 6.7.
If the READ path works on IPQ platforms it's already a huge step
forward, please send the fix on top of Mannivan series.
ok, will send. Please confirm if its all fine.
There are more abstraction/common mode in the driver to be pulled
out, but that will do later.
Now, what is the issue with SDX?
Looks like SDX device that Mani is having is a 4K nand device.
For some reason, after exec ops nand boot is broken on that board.
We applied the fixes we did on top of Manivannan series.
With that enumeration works, but still mount fails. But 4K nand
device boot on IPQ works fine. Problem is we do not have a SDX board
where we could debug that. We are trying to get a remote setup
enabled for this.
Regards,
Sricharan
