All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 03 Apr 2012 11:48:32 +0300	[thread overview]
Message-ID: <4F7AB960.1040502@compulab.co.il> (raw)
In-Reply-To: <1333380867.84262.YahooMailClassic@web29015.mail.ird.yahoo.com>

On 04/02/12 18:34, Paul Parsons wrote:
> Hello Haojian,
> 
> --- On Mon, 2/4/12, Haojian Zhuang <haojian.zhuang@gmail.com> wrote:
>>>>> But since DRIVE_HIGH or
>> DRIVE_LOW currently don't
>>>> prevent that,
>>>>
>>>> Don't prevent what?
>>>
>>> Don't prevent a GPIO input being changed to an output
>> when entering
>>> suspend().
>>>
>> PGSRx register allow for selecting the output state (the
>> driven value)
>> of each GPIO pin when the processor enters and while it is
>> in sleep
>> mode.
>>
>> Each bit of PGSRx register is named as SS (Sleep State of
>> GPIO<n>).
>>
>> SS '0' -- If GPIO is programmed as an output, the pin is
>> driven and held
>> low during the transition to and while in sleep mode.
>>
>> SS '1' -- If GPIO is programmed as an output, the pin is
>> driven and held
>> high during the transition to and while in sleep mode.
>>
>> So pin must be configured to GPIO output first before
>> entering sleep mode.
>>
>> Now the issue comes. If you use the pin as input, why do you
>> need to change
>> it into output mode in run time?
> 
> I cannot think of a reason why you would change an input to an output.

One reason, I can think of is bidirectional pins:
the direction can change several times during runtime, but
peripheral may require the pin to be in some defined state in suspend.

> 
> But the possibility that the direction could be changed from input
> to output has been cited as a reason why KEEP_OUTPUT cannot force
> the gpio direction to output.

Indeed, and that's why your patch is wrong - it does exactly that,
it enables the possibility to change the input to output and drive an
undefined level.

> 
> It is relatively easy to verify that KEEP_OUTPUT does not change the
> direction from input to output, because currently only 2 platforms
> use KEEP_OUTPUT, namely corgi and hx4700.

Again, with your patch it will make the change possible.

> 
> It is less easy to verify that DRIVE_HIGH and DRIVE_LOW do not change
> the direction from input to output, because many more platforms use
> them; a cursory check suggests that up to 16 platforms use them.

DRIVE_HIGH and DRIVE_LOW are used across several _different_ SoCs
and care must be taken while changing something related to them.

The DRIVE_HIGH and DRIVE_LOW in current implementation _can_ change
the inputs to outputs, but IMO it is the board support code
responsibility to verify that the right thing is done.

> 
>>
>>> By the way, there is still the issue of DRIVE_HIGH and
>> DRIVE_LOW
>>> forcing the GPIO direction to output in
>> pxa2xx_mfp_suspend()
>>> *before* the PGSR values take effect. Surely a bug?
>>>
>> It's evil to change pin from input mode to output mode if
>> it's in active mode.

Unless, it is peripheral requirement.

> 
> Agreed.
> 
> So pxa2xx_mfp_suspend() contains a potential bug, unless someone can
> verify that DRIVE_HIGH and DRIVE_LOW never change the direction from
> input to output.

They do, but I don't consider it a bug, but a flexibility.
When you specify DRIVE_HIGH or DRIVE_LOW in the board pin config,
you must know what you are doing and be responsible.


-- 
Regards,
Igor.

  reply	other threads:[~2012-04-03  8:48 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 [this message]
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
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=4F7AB960.1040502@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 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.