UBI on SPI NOR flash

[Artem Bityutskiy]

On Mon, 2012-09-03 at 11:44 +0200, Jan Lübbe wrote:
> Hi Artem,
> 
> On Mon, 2012-09-03 at 12:23 +0300, Artem Bityutskiy wrote:
> > On Mon, 2012-08-27 at 18:15 +0200, Jan Lübbe wrote:
> > > It works if I disable DMA in drivers/spi/spi-omap2-mcspi.c (simply
> > > comment out the DMA branch in omap2_mcspi_work). I can use UBI&UBIFS
> > > without problems for far. When rebooting to a kernel with DMA enabled
> > > I
> > > can no longer attach the previously working volume. Moving back to the
> > > PIO-Kernel, it works again.
> > > 
> > > Where should this be fixed? Should UBI use kmalloc'ed memory?
> > 
> > Yes, the best way to fix this is to teach UBI and UBIFS stop using
> > vmalloc(). It is not straight-forward, but doable. As I said several
> > times, I can assist by giving ideas and directions, but someone who
> > needs this should probably allocate a couple of men-months for this
> > project.
> 
> I can't commit to spending months on this, but I do have some time.
> Do you think the vmalloc-using places could be fixed step by step or
> must this be done over UBI&UBIFI in one go?
> Is there a specific thread where the approach fixing this has been
> discussed before? Could the CMA be used instead of vmalloc?

I believe it can be done step by step. You can start from UBI I guess.
Basically we use vmalloc everywhere when we need to read entire
eraseblock. The reason for this is that the eraseblock is large, so
kmalloc() would often fail.

So the idea is to allocate smaller buffers and then iterate. There are
places which are easier to handle, and some are more difficult to handle
(e.g., those where we index elements in the eraseblock array).

> You mentioned flexible arrays before. It seems it is targeted at items
> smaller than a page and needs to copy each item when placing it into the
> array. I'm not sure how this would help UBI/UBIF.

I think I meant something like flexible arrays. The idea was to create
an API which you can use as if you had a single vmalloc buffer. Indexing
operation then could be changed with a helper function.

> We probably also need an explicit way to tell MTD if a buffer is DMA
> capable or not. Then we could avoid deciding based on the buffer pointer
> in the storage drivers.

I think it is better to eliminate vmalloc from UBI/UBIFS.

> > > Why does this work for NAND controllers using DMA? :) 
> > 
> > I am not sure, you should investigate. I think some drivers just check
> > if this is vmalloced memory, and avoid DMA for that. Some (e.g.,
> > onenand) use various hacks which appear to work.
> 
> I was able to get it to work using this kind of hack (check in SPI host
> driver for buf >= high_memory and fall back to PIO). It's submitted to
> the SPI list, but I'm not sure if it's acceptable for them.

I hope not :-) We need to fix things properly.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120903/0ecbb3b6/attachment.sig>