From: grinberg@compulab.co.il (Igor Grinberg)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: pxa: mfp: Force gpio direction for MFP_LPM_KEEP_OUTPUT
Date: Thu, 12 Apr 2012 13:59:08 +0300 [thread overview]
Message-ID: <4F86B57C.1080506@compulab.co.il> (raw)
In-Reply-To: <1333470392.66217.YahooMailClassic@web29010.mail.ird.yahoo.com>
Hi Paul,
Sorry for a delay, I've been a bit busy with work...
On 04/03/12 19:26, Paul Parsons wrote:
> --- On Tue, 3/4/12, Igor Grinberg <grinberg@compulab.co.il> wrote:
>> Hmmm....
>> If we change the GPSR and GPCR, the old levels should be
>> reserved, right?
>> Attached...
>
> Yes, that sounds right: if resume() restores the old directions then
> it makes sense for it to restore the old levels first. Otherwise it
> encounters the same problem as suspend().
>
> On that very subject, I notice that __mfp_config_gpio() also sets
> directions without first setting levels.
Hmmm... this is not good, but...
>
> Problem is, it is not obvious what levels it should set.
> Perhaps it should likewise set the levels to the PGSR values, on the
> tenuous presumption that any hardware should already be in low power
> mode at the time __mfp_config_gpio() is called.
> But then again maybe not. This is more tricky.
Well, it looks like most of the cases the __mfp_config_gpio() is called
during init time and the levels are setup only later and PGSR still has
its reset values.
This leaves the direction outputs without a defined level, but having
the MFP_CFG_IN() as the default setting is the right thing and probably
assures the "safeness" of the __mfp_config_gpio().
Also, that is exactly why we should not use the MFP_CFG_OUT() directly.
I agree with you that probably the __mfp_config_gpio() function
should not touch the GPDR, but changing this has affect on all PXA2xx
boards, so I would *not* touch that until there is a real issue.
>
> I'll give the patches a try before the end of the day.
Thanks
--
Regards,
Igor.
next prev parent reply other threads:[~2012-04-12 10:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-31 12:20 [PATCH] ARM: pxa: mfp: Force gpio direction for MFP_LPM_KEEP_OUTPUT Paul Parsons
2012-04-01 9:15 ` Igor Grinberg
2012-04-01 10:56 ` Paul Parsons
2012-04-01 12:23 ` Igor Grinberg
2012-04-01 17:56 ` Paul Parsons
2012-04-02 8:39 ` Igor Grinberg
2012-04-02 11:30 ` Paul Parsons
2012-04-02 12:44 ` Igor Grinberg
2012-04-02 13:33 ` Paul Parsons
2012-04-02 14:58 ` Haojian Zhuang
2012-04-02 15:34 ` Paul Parsons
2012-04-03 8:48 ` Igor Grinberg
2012-04-03 8:01 ` Igor Grinberg
2012-04-03 12:30 ` Paul Parsons
2012-04-03 14:42 ` Igor Grinberg
2012-04-03 15:08 ` Igor Grinberg
2012-04-03 16:26 ` Paul Parsons
2012-04-12 10:59 ` Igor Grinberg [this message]
2012-04-04 1:00 ` Paul Parsons
2012-04-03 23:55 ` Paul Parsons
2012-04-05 8:16 ` Igor Grinberg
2012-04-05 11:15 ` Paul Parsons
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=4F86B57C.1080506@compulab.co.il \
--to=grinberg@compulab.co.il \
--cc=linux-arm-kernel@lists.infradead.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