From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26612 invoked by alias); 27 Aug 2008 05:22:05 -0000 Received: (qmail 26603 invoked by uid 22791); 27 Aug 2008 05:22:04 -0000 X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Aug 2008 05:21:30 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1KYDTB-0006kk-00; Wed, 27 Aug 2008 07:21:25 +0200 Date: Wed, 27 Aug 2008 07:12:00 -0000 From: Andrew Lunn To: Frank Pagliughi Cc: eCos Discussion Message-ID: <20080827052125.GB25863@lunn.ch> Mail-Followup-To: Frank Pagliughi , eCos Discussion References: <48B340BD.1050201@sorosys.com> <20080826044828.GS31987@lunn.ch> <48B4601F.5010607@mindspring.com> <48B47309.8090608@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B47309.8090608@mindspring.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes 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] Device driver open & close X-SW-Source: 2008-08/txt/msg00069.txt.bz2 >> This gets called for each open? Yes. Take a look at the code: io/fileio/current/src/devfs.cxx:dev_open() calls cyg_io_lookup() on the device. And then there is this comment: // // Look up the devtab entry for a named device and return its handle. // If the device is found and it has a "lookup" function, call that // function to allow the device/driver to perform any necessary // initializations. // Cyg_ErrNo cyg_io_lookup(const char *name, cyg_io_handle_t *handle) >>> You might be better using cyg_io_set_config() mechanism to turn it on >>> and off. >>> >> This is unfortunate. For another example, the system will have the >> ability to power down the compact flash drive(s). Which order should >> the power down happen? >> flush() the buffers, then cyg_io_set_config() to power down the >> drive, *then* close() ? I assume you can't use the handle to >> set_config after the close(). Right? File systems work differently. There you have a clean mount and unmount. So i would extend the mount and umount call to call the cyg_io_set_config() to power the device up/down. However you might have a problem with the partition table, > I'm just doing the OS port & device drivers for a board that has to > really conserve power and thus turn devices off and on a lot. Someone > else will write the application, so I'm trying to make the interface as > simple and familiar as possible (therefore standard I/O api). It seems > that the eCos device API assumes that devices will be initialized then > stay on forever. So, any ideas are appreciated. Well LCD devices don't always follow standard I/O. This is especially true if you are doing a windowing driver? Or is it plain text. And how is the driver structured? Maybe you maintain a frame buffer in local memory and blit it out to the LCD every so often? With the cyg_io_set_config() you can keep the frame buffer running all the time and use the cyg_io_set_config() to power up/down the LCD controller and start/stop blitting. Another cyg_io_set_config() would control the backlight etc. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss