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: 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 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.