linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

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