From: joravec@drewtech.com (Joey Oravec)
To: linux-arm-kernel@lists.infradead.org
Subject: plat-orion multi purpose pins problem for mv78200
Date: Thu, 07 Jul 2011 09:49:59 -0400 [thread overview]
Message-ID: <4E15B987.1060208@drewtech.com> (raw)
In-Reply-To: <CAMAG_eeO5EXML=nEfKkvbqz__UFQifUujjFrb4YKiOxZzdFhjA@mail.gmail.com>
On 7/7/2011 2:40 AM, saeed bishara wrote:
>>>> Note that orion_gpio_set_valid() and orion_gpio_is_valid() would
>>>> both need rework. The functions need to handle that a GPIO can be
>>>> mux'ed onto any MPP pin. I described this problem in another email
>>>> on the thread.
>>> I don't understand what's wrong with the GPIO array.
>> I tried to describe the case in my reply:
>> http://lists.arm.linux.org.uk/lurker/message/20110701.215657.7efe0a42.en.html
>>
>> Assume that we've solved the mpp_to_gpio mapping. Then imagine you pass a
>> large array to mv78xx0_mpp_conf() that includes:
>>
>> MPP16_GPIO (this mpp corresponds to GPIO16)
>> MPP47_UNUSED (this mpp corresponds to GPIO16)
>>
>> The code today processes the array in-order. When it processes MPP16_GPIO it
>> will mark the GPIO16 valid. When it processes MPP47_UNUSED it would
>> currently mark GPIO16 invalid. This is a problem because it still assumes a
>> 1:1 relationship.
> I agree, this is why we need some method to make the orion_mpp_conf()
> know which mpps are gpios, when that done, then the gpio of MPP47 in
> your case will not be set as invalid.
> one option to do that is to assume that mpp with _in == out_ == 0 is
> not a gpio. so the orion_mpp_conf() will look like this:
> --- a/arch/arm/plat-orion/mpp.c
> +++ b/arch/arm/plat-orion/mpp.c
> @@ -41,6 +41,7 @@ void __init orion_mpp_conf(unsigned int *mpp_list,
> unsigned int variant_mask,
> for ( ; *mpp_list; mpp_list++) {
> unsigned int num = MPP_NUM(*mpp_list);
> unsigned int sel = MPP_SEL(*mpp_list);
> + unsigned int gpio_num = MPP_GPIO(*mpp_list);
> int shift, gpio_mode;
>
> if (num> mpp_max) {
> @@ -64,9 +65,8 @@ void __init orion_mpp_conf(unsigned int *mpp_list,
> unsigned int variant_mask,
> gpio_mode |= GPIO_INPUT_OK;
> if (*mpp_list& MPP_OUTPUT_MASK)
> gpio_mode |= GPIO_OUTPUT_OK;
> - if (sel != 0)
> - gpio_mode = 0;
> - orion_gpio_set_valid(num, gpio_mode);
> + if (gpio_mode != 0)
> + orion_gpio_set_valid(gpio_num, gpio_mode);
> }
>
>
> and of course this will require that any non gpio mpp will have to
> have the _in and _out set to 0.
Yes this proposal is better for mv78xx0 than the current code, but it
may fail if you call orion_mpp_conf() multiple times. Imagine you setup
the MPP16_GPIO as described, then a subsequent call wants to configure
differently and sets:
MPP16_UNUSED (this mpp corresponds to GPIO16)
Note orion_gpio_set_valid() contains code to mark GPIOs as valid or
invalid, but proposed change will only make a call to mark a GPIO as
valid. This example would reconfigure the MPP but leave the GPIO marked
valid.
Eventually, we would need to handle this example to implement the
proposed pinmux API. Right?
-joey
next prev parent reply other threads:[~2011-07-07 13:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 19:14 plat-orion multi purpose pins problem for mv78200 Joey Oravec
2011-07-01 21:56 ` Joey Oravec
2011-07-02 12:23 ` Simon Guinot
2011-07-03 12:46 ` saeed bishara
2011-07-04 14:33 ` [PATCH v2] genirq: replace irq_gc_ack() with {set,clr}_bit variants Simon Guinot
2011-07-04 14:48 ` [PATCH v2] genirq: replace irq_gc_ack() with {set, clr}_bit variants Nicolas Pitre
2011-07-16 3:39 ` Kukjin Kim
2011-07-06 15:31 ` [PATCH v2] genirq: replace irq_gc_ack() with {set,clr}_bit variants Simon Guinot
2011-07-05 15:37 ` plat-orion multi purpose pins problem for mv78200 Joey Oravec
2011-07-06 16:18 ` Simon Guinot
2011-07-06 16:32 ` saeed bishara
2011-07-06 18:49 ` Joey Oravec
2011-07-07 6:40 ` saeed bishara
2011-07-07 13:49 ` Joey Oravec [this message]
2011-07-10 13:21 ` saeed bishara
2011-07-12 13:36 ` Joey Oravec
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=4E15B987.1060208@drewtech.com \
--to=joravec@drewtech.com \
--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).