linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: grinberg@compulab.co.il (Igor Grinberg)
To: linux-arm-kernel@lists.infradead.org
Subject: How to add GPIO outputs to the PXA2xx MFP configuration?
Date: Fri, 30 Mar 2012 20:59:51 +0300	[thread overview]
Message-ID: <4F75F497.50909@compulab.co.il> (raw)
In-Reply-To: <1333122733.41820.YahooMailClassic@web29002.mail.ird.yahoo.com>

On 03/30/12 18:52, Paul Parsons wrote:
> --- On Fri, 30/3/12, Igor Grinberg <grinberg@compulab.co.il> wrote:
>> On 03/30/12 18:06, Paul Parsons wrote:
>>> --- On Fri, 30/3/12, Igor Grinberg <grinberg@compulab.co.il>
>> wrote:
>>>> On 03/28/12 20:12, Paul Parsons
>>>> wrote:
>>>>> On PXA2xx platforms, the MFP API (described in
>>>> Documentation/arm/pxa/mfp.txt)
>>>>> provides values for the following:
>>>>>
>>>>> 1. GPIO inputs (e.g. GPIO105_GPIO).
>>>>> 2. Alternate function inputs (e.g.
>> GPIO105_CIF_DD_1).
>>>>> 3. Alternate function outputs (e.g.
>>>> GPIO105_KP_MKOUT_2).
>>>>>
>>>>> It does not provide values for GPIO outputs
>> (i.e. AF0
>>>> outputs).
>>>>>
>>>>> One cannot use the macro used by the MFP API
>> internally
>>>> - MFP_CFG_OUT() - to
>>>>> define new GPIO output values, since that macro
>> is
>>>> forbidden in platform code.
>>>>>
>>>>> Without the ability to add GPIO outputs to the
>> MFP
>>>> configuration, it is not
>>>>> possible to drive GPIO outputs high during
>> sleep mode.
>>>>>
>>>>> This would be useful, for example, on the
>> hx4700
>>>> platform, where driving the
>>>>> infrared powerdown GPIO 105 high during sleep
>> mode
>>>> would save some mA.
>>>>>
>>>>> So my question is: what method should one use
>> to add
>>>> GPIO outputs to the MFP
>>>>> configuration?
>>>>>
>>>>> One possible method, namely manually defining
>> values in
>>>> the platform code:
>>>>>
>>>>>      MFP_PIN_GPIO105 |
>> MFP_AF0 |
>>>> MFP_DIR_OUT | MFP_LPM_DRIVE_HIGH,
>>>>
>>>> Have you tried:
>>>> GPIO105_GPIO | MFP_LPM_DRIVE_HIGH,
>>>> ?
>>>>
>>>> This way it works on other boards.
>>>
>>> Hello Igor,
>>>
>>> GPIO105_GPIO expands to a GPIO input -
>> MFP_CFG_IN(GPIO105, AF0) -
>>> not an output.
>>
>> Yeah, I know... but read in mfp-pxa2xx.h, lines 6-20:
>> /*
>>  * the following MFP_xxx bit definitions in mfp.h are
>> re-used for pxa2xx:
>>  *
>>  *  MFP_PIN(x)
>>  *  MFP_AFx
>>  *  MFP_LPM_DRIVE_{LOW, HIGH}
>>  *  MFP_LPM_EDGE_x
>>  *
>>  * other MFP_x bit definitions will be ignored
>>  *
>>  * and adds the below two bits specifically for pxa2xx:
>>  *
>>  * bit     23 - Input/Output (PXA2xx
>> specific)
>>  * bit     24 - Wakeup Enable(PXA2xx
>> specific)
>>  */
>>
>> This means, that there is no difference between: MFP_CFG_IN
>> and MFP_CFG_OUT for PXA2xx.
> 
> The mfp-pxa2xx.c code says otherwise.

That's just great... outdated documentation...

> It uses the MFP direction bit
> to set the GPDR registers on entering sleep mode:
> 
>    353	static int pxa2xx_mfp_suspend(void)
>    354	{
>    355		int i;
>         ...
>    368		for (i = 0; i <= gpio_to_bank(pxa_last_gpio); i++) {
>    369	
>         ...
>    375			GPDR(i * 32) = gpdr_lpm[i];
>    376		}
>    377		return 0;
>    378	}
> 
> gpdr_lpm[] is initialized at startup to the current GPDR values, and
> thereafter is updated by the value of the MFP_DIR_OUT bit in calls to
> __mfp_config_gpio().

static int __mfp_config_gpio(unsigned gpio, unsigned long c)
{
	unsigned long gafr, mask = GPIO_bit(gpio);
	int bank = gpio_to_bank(gpio);
	int uorl = !!(gpio & 0x10); /* GAFRx_U or GAFRx_L ? */
	int shft = (gpio & 0xf) << 1;
	int fn = MFP_AF(c);
	int is_out = (c & MFP_DIR_OUT) ? 1 : 0;

[...]

	/* alternate function and direction@low power mode */
	switch (c & MFP_LPM_STATE_MASK) {
	case MFP_LPM_DRIVE_HIGH:
		PGSR(bank) |= mask;
		is_out = 1;
		break;
	case MFP_LPM_DRIVE_LOW:
		PGSR(bank) &= ~mask;
		is_out = 1;
		break;

And in the lines above, it gets overridden by MFP_LPM_DRIVE_*,
or am I missing something?
[...]

	if (is_out ^ gpio_desc[gpio].dir_inverted)
		gpdr_lpm[bank] |= mask;
	else
		gpdr_lpm[bank] &= ~mask;


So, I think,
GPIO105_GPIO | MFP_LPM_DRIVE_HIGH,
as I've proposed in my first email, should still work for you.

-- 
Regards,
Igor.

  reply	other threads:[~2012-03-30 17:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-28 18:12 How to add GPIO outputs to the PXA2xx MFP configuration? Paul Parsons
2012-03-30  1:33 ` Haojian Zhuang
2012-03-30 10:41   ` Paul Parsons
2012-03-30 13:25     ` Haojian Zhuang
2012-03-30 14:30       ` Paul Parsons
2012-03-30 14:50         ` Haojian Zhuang
2012-03-30 14:59 ` Igor Grinberg
2012-03-30 15:06   ` Paul Parsons
2012-03-30 15:28     ` Igor Grinberg
2012-03-30 15:34     ` Igor Grinberg
2012-03-30 15:52       ` Paul Parsons
2012-03-30 17:59         ` Igor Grinberg [this message]
2012-03-30 21:13           ` Paul Parsons
2012-03-30 21:40             ` 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=4F75F497.50909@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;
as well as URLs for NNTP newsgroup(s).