public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Frank Pagliughi <fpagliughi@mindspring.com>
To: eCos <ecos-devel@ecos.sourceware.org>
Subject: Re: Closing devices
Date: Mon, 18 Jun 2012 14:34:00 -0000	[thread overview]
Message-ID: <4FDF3C83.6050102@mindspring.com> (raw)
In-Reply-To: <4FDF355B.2010209@mindspring.com>

Hello All,

I'm looking for ideas on how to close and re-open devices on eCos. The 
needs for this are (1) to support swappable/removable devices, (2) to 
have a consistent way to put devices into a low-power state when they 
are not being used, and (3) to prevent devices from using the CPU when 
they are not needed.

On a current project for a battery-powered device, I have a need for all 
of this: a CompactFlash that can be removed; a GPS that sends data 
constantly, but only needs to be read once every few hours; and many of 
the peripherals need to be put in a consistent state prior to going into 
a low power mode.

I've been able to accomplish all of this with ugly application-level 
code, but thought that a much better solution would be to propagate the 
close() call of a devfs device down to the driver, so you could do this:

    while (true) {
         int fd = open("/dev/ser0", O_RDONLY);
         read(fd, buf, BUF_LEN);

         // power down the port
         close(fd);

         sleep(60);
    }

I think this can be done pretty easily by adding a "shutdown" function 
to the devtab entries:

    typedef struct cyg_devtab_entry {
         // ...
         Cyg_ErrNo        (*lookup)(struct cyg_devtab_entry **tab,
                                    struct cyg_devtab_entry *sub_tab,
                                    const char *name);
         Cyg_ErrNo        (*shutdown)(struct cyg_devtab_entry *tab);
         // ...
    } CYG_HAL_TABLE_TYPE cyg_devtab_entry_t;


The existing macros CHAR_DEVTAB_ENTRY, BLOCK_DEVTAB_ENTRY, etc, can just 
insert an empty function into the shutdown slot, whereas a new set of 
macros can accept the shutdown pointer:

    #define
    CHAR_CLOSABLE_DEVTAB_ENTRY(_l,_name,_dep_name,_handlers,_init,_lookup,_shutdown,_priv)
    ...
    #define
    BLOCK_CLOSABLE_DEVTAB_ENTRY(_l,_name,_dep_name,_handlers,_init,_lookup,_shutdown,_priv)
    ...

The assumption is that anything done in the shutdown would be undone in 
a subsequent lookup so that the devices could bre closed then re-opened, 
and that the shutdown would mark the entry as "unavailable":

    tab->status &= ~CYG_DEVTAB_STATUS_AVAIL;


Assuming that this is a good way to handle this I would need to know how 
to hook this into the upper-level device and file operations. What would 
be needed?

Thanks,
Frank

  parent reply	other threads:[~2012-06-18 14:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-12 12:34 Handling RTS with an UART that doesn't directly drives the RTS pin Bernard Fouché
2012-06-12 13:12 ` Stanislav Meduna
2012-06-12 13:16 ` Nick Garnett
2012-06-12 16:56   ` Bernard Fouché
2012-06-13 10:10     ` Nick Garnett
2012-06-13 16:37       ` Bernard Fouché
2012-06-14 15:33         ` Bernard Fouché
     [not found] ` <4FDF355B.2010209@mindspring.com>
2012-06-18 14:34   ` Frank Pagliughi [this message]
2012-06-19 13:36     ` Closing devices Bernard Fouché
2012-06-20 13:38       ` Frank Pagliughi
2012-06-20 15:20         ` Bernard Fouché
2012-06-21 18:20           ` Frank Pagliughi
2012-06-22  8:33             ` Bernard Fouché
2012-06-22 14:48               ` Frank Pagliughi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FDF3C83.6050102@mindspring.com \
    --to=fpagliughi@mindspring.com \
    --cc=ecos-devel@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).