public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: "Bernard Fouché" <bernard.fouche@kuantic.com>
To: ecos-devel@ecos.sourceware.org
Subject: Re: Closing devices
Date: Tue, 19 Jun 2012 13:36:00 -0000	[thread overview]
Message-ID: <4FE0804A.5050002@kuantic.com> (raw)
In-Reply-To: <4FDF3C83.6050102@mindspring.com>


Le 18/06/2012 16:34, Frank Pagliughi a écrit :
> 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:
Hello Frank,

I have the exact same needs and I also made my changes in the 
application code at the moment, for the same reasons. However if we look 
at the low level details:

-  The Init() function of a driver is called at boot time,  a time you 
don't want to initialize much things if you don't know yet if you'll 
need them a few moment later. init() isn't visible from anything else 
than the startup procedure of eCos.

- lookup() is called when the application 'opens' a channel of a driver. 
Usually nothing much is done at low level since the assumption is that 
init() made the job before. However it's possible to rework the drivers 
to change this and future drivers could be written with this in mind.

- Since a devtab entry can be looked up many times, even by different 
threads, it is probably necessary to have a driver to count the number 
of times it is looked up and the number of times it is shutdown. When 
the count reaches zero, then the driver knows it can power off things.

- drivers that are shared between different targets do not know about 
target specific features, by design they focus on the parts that are 
common to all targets they can be used on. Such a driver expects that 
the MCU pin setup (and other details) has already been done earlier in 
the board init code, it has no way to query something to run again this 
procedure. If you need to close an UART, you probably also want to 
reconfigure the MCU's pins. You may also want to power off the UART 
(from the MCU point of view) if the MCU allows it. So even if shutdown() 
is implemented, such a driver wouldn't do much regarding power savings, 
at best it could only mask or disable an interrupt, the most important 
savings must be handled elsewhere. Even if the board init code could be 
accessible, how one could ask this code to perform a partial 
initialization? (for instance to avoid reconfiguring all UARTs while a 
single one is to be re-initialized).

- power management is very MCU/board/application specific and project 
specific code will have different things to do. For instance if you have 
an external RS232 device, you save more power by turning off the level 
converter between the UART and the RS232 connector. Of course it's 
better to be able to turn off both the UART in the MCU and the level 
converter. If you don't have a level converter, you may want to 
reconfigure the MCU pins, for instance to avoid having power drawn from 
the UART TX pin if the connected device is  also powered off. You may 
also want to setup pull-up/down on the pins to stabilize the signals: it 
means changing the pin setup of the MCU to change them from 'UART' to 
'GPIO' and then configure the pull up/down feature. You  may also want 
to change peripheral clock settings for disabled peripheral in the MCU, 
to spare a bit more so you have to re configure also clocking registers 
when the peripheral must come back in line.

- There is CYGPKG_POWER. Each driver implementing some kind of power 
management can be modified to support this package. But I don't see how 
this package can interact with the platform code layer. How can a target 
using a shared driver can make use of this package for the shared driver?

IMHO, beside a shutdown mechanism, one also needs to be able to get 
control of what's going on between the hardware drivers and the packages 
that use them. A low level application initialization routine should be 
able to register callbacks to be triggered when events occur in the 
drivers and in the package code managing them, hence the application 
could handle the board or MCU specifically when some expected event 
occurs. Today only part of this could be done in platform code, but in 
such a way that it is very close to application code, however without 
any clearly defined API.

     Bernard

  reply	other threads:[~2012-06-19 13:36 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   ` Closing devices Frank Pagliughi
2012-06-19 13:36     ` Bernard Fouché [this message]
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=4FE0804A.5050002@kuantic.com \
    --to=bernard.fouche@kuantic.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).