On Tue, Dec 17, 2013 at 10:49:51AM +0530, Sourav Poddar wrote:
> On Tuesday 17 December 2013 08:26 AM, Huang Shijie wrote:
> >On Tue, Dec 17, 2013 at 12:11:58AM +0530, Sourav Poddar wrote:
> >>>+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.
> >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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
