Re: [ECOS] Non-contiguous flash with flashv2

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Daniel" == Daniel Helgason <dhelgason@shaw.ca> writes:

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

    Daniel> Thanks Andrew. That's what I implemented.

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

Theoretically possible but I think it adds unnecessary complexity.
Your current behaviour is very similar to what already happens for
e.g. dataflashes on an SPI bus: there is a mutex at the flash driver
level, and a lower-down mutex at the SPI bus level. A mutex is a
fairly small object, so memory consumption is not a big issue. Locking
and unlocking an uncontested mutex are cheap operations, completely
negligible compared with actually performing a flash write or erase.

However, if you make the locking behaviour configurable then soner or
later somebody is going to get it wrong. A user may misunderstand the
option and set it inappropriately, or a new driver may do the wrong
thing. Then you end up with a system where flash mostly works, but
very occasionally you could have two threads accessing a flash device
at the same time with no mutex to protect against that, and you would
have bad things happening. That kind of bug is very hard to track
down.

Plus, you are adding complexity to the generic flash package and that
new code would need testing somehow, and long-term maintenance,

So let's keep things simple. The current approach works fine for most
current hardware. On some hardware it may involve an extra mutex and a
bit of extra locking, but the overheads are small.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

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