Hi Pekka,
> Attached.
In the future, can you please use git-send-email so that I can comment on the
patch much easier.
>
> > So far I like the idea of disable having a
> > hint on whether a shutdown is in progress more than an explicit shutdown
> > method.
>
> That is also possible, but then
Hi Denis,
2010/4/1 Denis Kenzior :
>> What we miss from the core is a way to do asynchronous cleanup
>> (separate from Powered). A shutdown() method in modem driver and
>> corresponding callback, like ofono_modem_shutdown_ready(). This way we
>> can do what ever N900 requires us to do and there is
Hi Aki,
> to, 2010-04-01 kello 11:14 +0200, ext Pekka Pessi kirjoitti:
> > It seems to me that Marcel and Aki want to control TX power with the
> > Powered property. (BTW, there already is a post-sim mechanism to
> > control the RX/TX, namely Register/Deregister.)
>
> But then Register()'s meanin
Hi Pekka,
> I want to prevent core from exiting while a modem is in transitional
> state. Before ofonod terminates, it calls disable and waits until
> Powered gets false. I'd rather change Powered to false immediately
> (when modem shutdown starts) but still keep waiting until modem is
> properly
to, 2010-04-01 kello 11:14 +0200, ext Pekka Pessi kirjoitti:
> It seems to me that Marcel and Aki want to control TX power with the
> Powered property. (BTW, there already is a post-sim mechanism to
> control the RX/TX, namely Register/Deregister.)
But then Register()'s meaning is overloaded to me
Hi Denis,
2010/3/31 Denis Kenzior :
>>
>> 1) and 2) are already done through D-Bus, only thing is missing is
>> oFono core properly supporting transitions between Powered false and
>> true.
>
> So I just checked again, and we remove all atoms when turning off (even if off
> subsequently fails). S
Hi Pekka,
> >> I'm trying to
> >> 1) load atoms only after when isimodem is up and running and reset the
> >> state of the isimodem atoms in case the isimodem reboots (or user
> >> turns off a Nokia handset connected via USB)
> >> 2) have asyncronous probe and remove
> >> 3) separate rf state and
2010/3/30 Marcel Holtmann :
>> >> > So I'm still having trouble understanding the issue. When oFono calls
>> >> > disable, the driver is expected to take all necessary steps to disable
>> >> > the
>> >> > modem. If that means waiting N seconds after the command has been
>> >> > sent, so be
>> >
2010/3/30 Denis Kenzior :
> We need to look closely at whether enabling flight mode (e.g. SIM on, while
> TX/RX is off) makes sense. It is something we should consider, but
> challenging
> since most of the SIM attributes are exposed through atoms which won't be
> generally available when in Flig
Hi Aki,
> 2010/3/30 Denis Kenzior :
> > The answer is that exposing this as a property is not going to happen
> > because it is fundamentally wrong. And in effect it already is exposed,
> > e.g. the fact that modem object is present in oFono. You have several
> > options here:
>
> So I think wh
Hi Pekka,
> >> > So I'm still having trouble understanding the issue. When oFono calls
> >> > disable, the driver is expected to take all necessary steps to disable
> >> > the
> >> > modem. If that means waiting N seconds after the command has been sent,
> >> > so be
> >> > it. During shutdow
2010/3/30 Denis Kenzior :
> The answer is that exposing this as a property is not going to happen because
> it is fundamentally wrong. And in effect it already is exposed, e.g. the fact
> that modem object is present in oFono. You have several options here:
So I think what you are saying is that
Hi,
2010/3/30 Marcel Holtmann :
>> It seems to me that Marcel thinks "Powered" should control the RF
>> state, too. So, a separate property for enabling he RF would be nice,
>> too.
>
> That is what I call RFKILL and we have a proper subsystem for that. And
> it is different from your Power-1 and
2010/3/30 Marcel Holtmann :
>> > So I'm still having trouble understanding the issue. When oFono calls
>> > disable, the driver is expected to take all necessary steps to disable the
>> > modem. If that means waiting N seconds after the command has been sent,
>> > so be
>> > it. During shutdown
Hi Pekka,
> Sure.
>
> I want Powered-1 that controls the atoms. Atoms should be loaded when
> modem is in responsive state and removed when, e.g., modem reboots.
> This we can do now, iow, if you connect a Nokia phone via USB, oFono
> can follow its state via the MTC indications it sends on top o
Hi Pekka,
> >> That is also a problem. The other problem is that the party
> >> controlling the modem power state is supposed to keep GPIO lines in
> >> known position for a while after the modem has indicated it has been
> >> powered down. In an N900 running maemo, a daemon called sscd does
> >>
Hi Denis,
2010/3/30 Denis Kenzior :
>> That is also a problem. The other problem is that the party
>> controlling the modem power state is supposed to keep GPIO lines in
>> known position for a while after the modem has indicated it has been
>> powered down. In an N900 running maemo, a daemon call
Hi Pekka,
> >> I've been porting the N900 modem control code to oFono. The semantics
> >> of Powered is fine with respect of the atoms, in other words, if the
> >> modem crashes and boots itself, all the atoms are flushed nicely.
> >> When powering up, the Powered can be set to true when the modem
Hi Aki,
> > Another solution is to use sscd-like daemon also with ofono (the oFono
> > Powered property would then just follow the power state of the modem).
>
> My preference would be to have these things handled as oFono plugins.
> That being the recommended way of course doesn't preclude some
Hi Pekka,
> That is also a problem. The other problem is that the party
> controlling the modem power state is supposed to keep GPIO lines in
> known position for a while after the modem has indicated it has been
> powered down. In an N900 running maemo, a daemon called sscd does
> that. sscd exit
ti, 2010-03-30 kello 13:36 +0200, ext Pekka Pessi kirjoitti:
> Another solution is to use sscd-like daemon also with ofono (the oFono
> Powered property would then just follow the power state of the modem).
My preference would be to have these things handled as oFono plugins.
That being the recomm
2010/3/29 Bastian, Waldo :
> Pekka Pessi wrote:
>> I've been porting the N900 modem control code to oFono. The semantics
>> of Powered is fine with respect of the atoms, in other words, if the
>> modem crashes and boots itself, all the atoms are flushed nicely.
>> When powering up, the Powered can
2010/3/29 Denis Kenzior :
>> However, then powering modem down, there are problems. The N900 modem
>> control needs to make difference between the state where the modem is
>> no more useful and the safe-to-exit state when the power off request
>> has been completed, modem has flushed its state to f
Hi Pekka,
> However, then powering modem down, there are problems. The N900 modem
> control needs to make difference between the state where the modem is
> no more useful and the safe-to-exit state when the power off request
> has been completed, modem has flushed its state to flash and given
> so
Pekka Pessi wrote:
> I've been porting the N900 modem control code to oFono. The semantics
> of Powered is fine with respect of the atoms, in other words, if the
> modem crashes and boots itself, all the atoms are flushed nicely.
> When powering up, the Powered can be set to true when the modem is
Hi denis,
2010/3/19 Denis Kenzior :
> I've been talking about this exact issue with Marcel but so far we have not
> firmly agreed on any solution. Our current thinking is to keep Powered
> semantics as they are, but to also add Flight mode property. This would in
> affect allow interaction with
Hi Pekka,
> Hi all,
>
> I think the Modem "Powered" property is meant to control the radios
> (something like at+cfun=0 vs. at+cfun=1..). Now core automatically
> removes all the atoms in case modem has "Powered" false. However, the
> SIM card should be accessible while the radios are off (cfun=0
27 matches
Mail list logo
