Re: once more psh3pwr(4)

On Tue, Sep 25, 2007 at 00:32:21 +0900, KIYOHARA Takashi wrote:

> From: "Valeriy E. Ushakov" <[email protected]>
> Date: Sun, 23 Sep 2007 22:08:56 +0400
> 
> > On Mon, Sep 24, 2007 at 01:42:53 +0900, KIYOHARA Takashi wrote:
> 
> > > 	/* regsiter sleep function to APM */
> > > 	__sleep_func = psh3pwr_sleep;
> > > 	__sleep_ctx = self;
> > 
> > Also arrange necessary config_hooks to get hpcapm connected to this
> > driver?
> 
> hmm.. I can't know your meaning.  X-<

This is to make apm(8) work.  apm(8) queries apm device and that ends
un in hpcapm(4).  hpcapm uses config hooks to ask real "power" device
about things like A/C adapter plugged/unplugged, battery state, etc.
Check how it's done in j6x0pwr(4).

E.g. on my jornada with the battery not inserted (the deice is always
on external power):

    # apm
    Battery charge state: absent
    Battery remaining: 0 percent (0 minutes)
    A/C adapter state: connected
    Power management enabled


> > > 	sc->sc_data.sensor = 0;
> > > 	sc->sc_data.units = ENVSYS_INDICATOR;
> > > 	sc->sc_data.state = ENVSYS_SVALID;
> > > 	sc->sc_data.value_cur = sc->sc_plug;
> > > 	snprintf(sc->sc_data.desc, sizeof(sc->sc_data.desc),
> > > 	    "%s %s", sc->sc_dev.dv_xname, "plug");
> > 
> > I wonder if it makes sense to convert hpcapm to use sysmon instead of
> > doing that in each driver (just thinking out loud here).
> 
> In a word, should we treat sysmon_envsys with hpcapm layer?

I haven't checked how real i386 apm plugs into sysmon_envsys, but we
probably should make hpcapm congruent with the real one.  Since hpcapm
already queries real power device about e.g. A/C adapter state via
config hook, it seems logical to have sysmon glue in one place
(hpcapm).  But again, I haven't actually looked and havben't thought
it through.


> > > 	/* splhigh on entry */
> > > 	extern void pfckbd_poll_hitachi_power(void);
> > 
> > I assume this will be in pfckbd.c.  Isn't there any interrupt to wake
> > us up?
> 
> Oops.
> Yes.  Our PERSONA not occur the interrupt to power-button with on/off.
> Therefore, we are setting *_ special_keymap in hpckbdkeymap.h.  And,
> KEY_SPECIAL_OFF is detected with hpckbd.c.

I remember we discussed this.  How does WinCE handles wakeup on
PERSONA then?  It would be very nice to add real suspend when Jared's
PM branch is merged to the trunk.  On Jornada WinCE does a very clever
trick for the suspend - it powers down everything and puts memory into
self-refresh mode, but just before that it prefetches interrupt
handler into the CPU cache, so that when wakeup interrupt occurs CPU
can run that interrupt handler out of cache (preserved in sleep) and
the handler brings memory back from self-refresh and then jumps into a
real handler that is in the memory.  If there's no wakeup interrupt in
PERSONA I wonder how can they implement efficient suspend at all.


But anyway, commit and let's figure out the details when the code is
in the tree.

Thanks.

SY, Uwe
-- 
[email protected]                       |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen