From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25280 invoked by alias); 10 Dec 2008 01:24:57 -0000 Received: (qmail 25268 invoked by uid 22791); 10 Dec 2008 01:24:56 -0000 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Dec 2008 01:24:03 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 572813F8007; Wed, 10 Dec 2008 01:24:01 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY2AG3KXfOqj; Wed, 10 Dec 2008 01:24:00 +0000 (GMT) Message-ID: <493F1A2E.10101@eCosCentric.com> Date: Wed, 10 Dec 2008 06:10:00 -0000 From: Jonathan Larmour User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Daniel Helgason CC: Andrew Lunn , ecos-discuss@ecos.sourceware.org References: <1228346350.3053.13.camel@localhost.localdomain> <20081204063325.GN27015@lunn.ch> <1228759213.3047.50.camel@localhost.localdomain> In-Reply-To: <1228759213.3047.50.camel@localhost.localdomain> OpenPGP: id=A5FB74E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Non-contiguous flash with flashv2 X-SW-Source: 2008-12/txt/msg00069.txt.bz2 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