All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonas Bonn <jonas@southpole.se>
To: ofono@ofono.org
Subject: Re: [PATCH v2 1/1] he910: reset modem after IO disconnect
Date: Thu, 08 May 2014 08:41:13 +0200	[thread overview]
Message-ID: <536B2709.7040200@southpole.se> (raw)
In-Reply-To: <536A5F13.3080405@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4277 bytes --]

Hi Denis,

(Merging your two responses into one here...)

On 05/07/2014 06:03 PM, Denis Kenzior wrote:> Hi Jonas,
>
> <snip>
>
>>
>> The control port is still usable so it doesn't appear that it HUP's.
>
> Hah, so why would they HUP the modem port instead of sending a NO CARRIER.

That I can't tell you... but nothing with this modem surprises me
anymore! :)

>
> By the way, the newer HE910 firmware does not turn off the SIM card when
> CFUN=4 is issued.

Interesting...  I'll need to try to get some updated documentation from
Telit then.


>
>>  Somehow we need to be able to recreate this data structure, but since
>> it's created in the modem's init function it won't be unless we "power
>> down" the modem (or something along those lines).
>
> You would need to re-create the affected atoms.  In this case this would
> be the gprs-context atom.

The gprs-context is created in post_online... we require functioning
communication to the modem to get that far.

When the modem or aux port HUP's, io_disconnect cleans up the at_chat
and chat structures associated with it.  This means that the
command_queue disappears and no more commands can be sent to the modem
via that chat (which we still reference).  We can hook into
user_disconenct to find out that the chat has been cleaned up and drop
our references, but we need to get the modem back on its feet again by
reopening the modem and aux ports and redoing the modem initialization.

>
>>
>> Suggestions for a better way forward welcome...
>>
>
> Is SIM hotswap actually supported by this hardware?  The only HE910
> samples I have are miniPCI Express cards.  For those it is unlikely that
> a hotswap function is even possible.  Are you getting proper QSS
> notifications on the control port when the SIM is removed / inserted?

SIM hotswap is definitely supported by this hardware.

QSS notifications work perfectly and ofono_simi_inserted_notify is
invoked properly via the switch_sim_status function.  The modem I have
is BGA-type soldered onto board and SIM holder pops out through unit's
case to allow for easy SIM swap.

And SIM hotswap works fine with the patches I have sent... even if
thoses patches maybe aren't 100% correct.  But I'm not really sure what
100% correct would be for this case since we're essentially trying to
work around a modem quirk (bug?) in that it HUP's occasionally.  That's
where I need your help! :)

On 05/07/2014 06:28 PM, Denis Kenzior wrote:
> Hi Jonas,
> 
> <snip>
>>
>> This patch also addresses a secondary issue whereby killing ofono during
>> an active connection causes the AUX port to report HUP when ofono is
>> restarted.
>>
> 
> I'm not quite sure how this patch would fix the above.  The order of
> events is the same between kill/restart and a modem reset.  I guess the
> only difference is that you don't send a CFUN=4 during a modem reset.
> 

I think it might be related to the fact that the modem (according to
documentation) requires that 10 seconds elapse between transitions from
CFUN 1 to 4 and vice versa.  Restarting ofono presumably is quicker than
this and results in a CFUN  1 - > 4 -> 1 transition that is too fast and
the AUX port HUP's as a result.  Simply retrying the initialization (as
the modem_reset patch does) gets us around this.

(I haven't really checked, but maybe the AUX port doesn't HUP if we wait
a bit before restarting ofono).

>> How about this approach instead?  Using ofono_modem_reset has pretty
>> much the same effect as my previous patch and _feels" correct...
> 
> ofono_modem_reset is intended for firmware crashes and getting back to
> previous state quickly.  This is a creative hack, but has some
> side-effects you might not intend (e.g. the modem might go online
> without being told explicitly)
> 
> I don't really mind the patch, but would explore the 'proper' avenues
> (e.g. ofono_sim_inserted_notify) first.

Like I said above, this is in place and works in the unpatched code.
The issue at hand is that the modem HUP's: the modem port when the SIM
card is pulled and the aux port when ofono is restarted.

Maybe this issue goes away with a firmware update... will need to look
into that, too.

/Jonas

  reply	other threads:[~2014-05-08  6:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-02 14:15 [PATCH 1/1] he910: set modem unpowered after IO disconnect Jonas Bonn
2014-05-06 13:38 ` Denis Kenzior
2014-05-07  6:29   ` Jonas Bonn
2014-05-07 16:03     ` Denis Kenzior
2014-05-07 12:14   ` [PATCH v2 1/1] he910: reset modem " Jonas Bonn
2014-05-07 16:28     ` Denis Kenzior
2014-05-08  6:41       ` Jonas Bonn [this message]
2014-05-08 14:06         ` Denis Kenzior

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=536B2709.7040200@southpole.se \
    --to=jonas@southpole.se \
    --cc=ofono@ofono.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.