Re: [ECOS] Non-contiguous flash with flashv2

[Jonathan Larmour <jifl@eCosCentric.com>]

Daniel Helgason wrote:
> 
> 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.

There's probably a better way to abstract this than making it an option -
it's an intrinsic property of the driver and should be set automatically.
After all, we want to support multiple different drivers in a system, with
completely different properties.

It imagine it could be expressed some way via some variant of the
CYG_FLASH_DRIVER macro. An initial thought is CYG_FLASH_DRIVER_NO_LOCK for
the case with no locks so the driver is responsible for locking if any is
required. Then you can also have CYG_FLASH_DRIVER_SHARED_LOCK  (better name
suggestions welcomed) to which you pass, along with the usual stuff,
another CYG_FLASH_DRIVER instance with which you share the same mutex lock.

The ability to selectively push locking into the driver would be worthwhile
- it would make it feasible to support operations like erasing of entire
planes. The above would make it possible I believe.

But in the most common case, we don't want to increase the porting effort
of individual drivers by requiring them to always do locking themselves,
IMHO. So anything which requires changing existing drivers should be
considered a no-no, especially since it should be after eCos 3.0.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

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