UBI on SPI NOR flash

[Jan Lübbe]

On Mon, 2012-09-03 at 13:00 +0300, Artem Bityutskiy wrote:
> On Mon, 2012-09-03 at 11:44 +0200, Jan Lübbe wrote:
> > 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.

Ok.

> 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.

Would you then iterate inside of UBI using this API, making page-sized
calls to MTD? Or would MTD need to be extended to pass around these
"DMA-lists"?

Do we need multiple large buffers at the same time for one UBI device?
If not, we could get one EB-size buffer from CMA on probe/mount and
reuse it.

> > 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.

So in the end, MTD drivers would expect to only receive DMA capable
buffers?

> > 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.

It's the same approach as taken by some NAND drivers. :-)

Regards,
Jan
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |