Re: flash driver interface improvement

[Jani Monoses <jani at iv dot ro>]

What do you mean by uniform sector layout ?Fixed erase size?
If yes then I also thought about how this might be done...
Mostly because I only saw flash chips with a small number or various 
sized blocks and then the large equally sized blocks (top or bottom boot variants)
If there are other then what I'm going to describe below is not generic enough :(
So just like the intel 28Fxxxx does we could have a struct in the upper layer
which contains the number of special blocks and their sizes (also top or bottom)
So the lower layer might not need to pass up a callback instead it could just fill
that structure with its values.
The code to check which block we are in while erasing/programming could be device independent..
And this could be backwards compatible as well since drivers which don't fill those fields
are presumed old type.Say we add these new fields at the end of flash_info and if low level says
block_size = 0 the upper knows it filled the new fields.Anyway backward compatibility is not that big
of an issue if we can configure almost anything.New drivers will just require something to be defined 
and then some ifdefs in the upper layer do their work.
What do you think?

> Hi all,
> 
> it appears to me that the current flash driver interface is
> very inflexible, supporting only flash chips with uniform
> sector layout. I'd therefore like to propose an extension that
> I am going to describe below, and that I would volunteer to
> implement if the ecos maintainers agree to this proposal.
> 
> The idea goes as follows: If during initialization the driver
> returns a non-zero sector size (as all existing drivers are
> supposed to do), the everything stays as it is now, thus
> backward compatibility is ensured. A flash driver implementation
> that wants to support a non-uniform sector layout returns a
> sector size of zero (0x0), and it provides a function for
> its clients to call with a sector index as an argument, that
> returns a sector descriptor struct giving the base address,
> size, and maybe other information about that sector.
> 
> Any comments?
> 
> tk
> ----------------------------------------------- 
> Thomas Koeller, Software Development 
> 
> Basler Vision Technologies 
> An der Strusbek 60-62 
> 22926 Ahrensburg 
> Germany 
> 
> Tel +49 (4102) 463-390 
> Fax +49 (4102) 463-46390
> 
> mailto:Thomas.Koeller@baslerweb.com 
> http://www.baslerweb.com 
> 
>