Re: [ECOS] Non-contiguous flash with flashv2

[Daniel Helgason <dhelgason@shaw.ca>]

On Thu, 2008-12-04 at 07:33 +0100, Andrew Lunn wrote:
> > Take 2:
> > 
> > If I define two flash drivers that share code, then each driver will
> > have a single block_info that covers just the valid area:
> > 
> >   Driver 1
> >   - block_info[0] - program flash
> >   Driver 2
> >   - block_info[0] - boot flash
> 
> This is what was intended when i designed the API.
> 
> However, i did not think of your case, multiple FLASH devices hanging
> off one controller. 
> 
> The mutex is there to stop multiple threads accessing the same flash
> device. That is still valid for you.
> 
> However the fact that there is one controller is hidden from the flash
> API layer. You register two different devices. So your controller
> mutex should be lower down. The device specific driver needs to
> implement the mutex. 
> ...

Thanks Andrew. That's what I implemented.

It seems a bit of a pity to have to take two mutexs to perform a flash
operation. Would it be worth considering making the locking strategy a
configurable option in io/flash? Perhaps the choices could be none,
common, or per-driver.

If 'none' is selected, then flash drivers can implement their own
locking if they want. This would have to assume that the flash drivers
are aware of each others resource requirements. In smaller MPUs with
built-in flash and no external bus this restriction shouldn't be a
problem.

If 'common' is selected, then the io/flash layer would supply a single
lock that covers all drivers. Only a single flash driver could ever be
actively working at a time. This would have to assume that flash
operations complete in a timely manner.

If 'per-driver' is selected, then io/flash would do what it does now -
manage a lock for each flash driver.

To implement this would require changes to io/flash, of course, but I
don't think any of the existing v2 flash drivers would have to be
changed.

It comes to my mind as I write this email that maybe this idea would
impact flash drivers controlling NAND or serially accessed memory
devices. In fact the more I think about it, the less onerous having to
take two mutexes appears. Wishy-washy, eh?!

-- 
+---------------------------------------------
| Daniel Helgason <dhelgason@shaw.ca>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss