Re: Support of removable MTD devices and other advanced features (follow-up from lkml)

["Jörn Engel" <joern@logfs.org>]

On Thu, 22 May 2008 19:47:02 -0700, Alex Dubov wrote:
> 
> > 
> > But nothing below the FTL should ever know about a logical block at all.
> > Why pass it on?
> 
> Media class specific backend must know it, to populate media's oob structure.
> TI's smartmedia adapter, for example, wants to know it itself (it has a
> hardware register for it).

Interesting.  Do you have a spec for that?

I would have expected two kinds of controllers.  "Smart" ones that
essentially export a block device interface and do all FTL work
themselves and dumb ones that allow raw flash access and require and FTL
in software.  Didn't know there were mixtures of the two.

> > We can replace the data pointer with a struct bio_vec.  In fact, I am
> > wondering whether we could just use a struct bio instead of struct
> > mtd_request.
> > 
> 
> Passing the whole struct bio is an overshoot for what we want to support. It
> has plenty of functionality that to my opinion would never be supported by dumb
> flash controllers.

After having a closer look at it I tend to agree.  Nevertheless there
are tons of similarities between block devices and mtd and I would like
them to become as similar as reasonably possible.  So right now I'd
create a struct fio (flash io) and copy any fields that make sense for
both from struct bio. 

> I thought, something simple would be enough, as long as it can handle buffer
> fragmentation and give the backend access to the actual struct page for mapping
> operation. It doesn't matter if this is a scatterlist or bio_vec (they are
> mostly the same). What's matter is an ability to obtain several chunks of the
> buffer in some not too obtrusive way.
> 
> Host controller will get a buffer chunk, and set up a dma into it. When it
> catches dma boundary event, it'll get another chunk, while still in the
> interrupt handler (as much as needed). If controller happens to have a real sg
> dma, it can call mtd_get_buf_sg several times in advance to populate the sg
> table.
> 
> Controllers lacking dma capability can do exactly the same using mtd_get_buf.

Makes sense.  And one hopes that most controllers don't require busy
waits and either send an interrupt or allow setting a timer as a poor
man's interrupt.

Jörn

-- 
Homo Sapiens is a goal, not a description.
-- unknown