On Tue, Dec 17, 2013 at 10:49:51AM +0530, Sourav Poddar wrote:

On Tuesday 17 December 2013 08:26 AM, Huang Shijie wrote:

quoted

On Tue, Dec 17, 2013 at 12:11:58AM +0530, Sourav Poddar wrote:

quoted

quoted

+static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t *retlen, u_char *buf)
+{
+	struct spi_nor *nor = mtd_to_spi_nor(mtd);
+	int ret;
+
+	dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
+
+	ret = spi_nor_lock_and_prep(nor, SPI_NOR_OPS_READ);
+	if (ret)
+		return ret;
+
+	/* Wait till previous write/erase is done. */
+	ret = wait_till_ready(nor);
+	if (ret)
+		goto read_err;
+

Can you shift "wait_till_ready" above spi_nor_lock_and_prep?
One usecase for asking for above change is that I am planning to
use this _prep api for switching to memory mapped mode for read and once
I am switched to mmap mode, read_sr calls in wait_till_ready will not
work for me.

you can implement your own wait_till_ready here.

I think no point doing this, since it does the same function for me.

quoted

Only we have grabbed the lock, then we can do the transactions with the NOR.

We can not call the wait_till_ready before we grab the lock, it is wrong.


If you really can not implement your own wait_till_ready, the final solution
is removing the wait_till_ready in this function, and add the wait_till_ready
in the nor->read() hook.

Yes, this can be done. So, that if you want to do memcpy do it before this
condition is hit.

ok. 

I can fix it in the next version.


thanks
Huang Shijie