Re: [PATCH] omap3: mux: add shorthands for OUTPUT_PULL{UP,DOWN}

[Mike Rapoport <mike@compulab.co.il>]

Tony Lindgren wrote:
> * Mike Rapoport <mike.rapoport@gmail.com> [091130 13:57]:
>> On Mon, Nov 30, 2009 at 11:12 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> * Mike Rapoport <mike@compulab.co.il> [091129 00:10]:
>>>> Signed-off-by: Mike Rapoport <mike@compulab.co.il>
>>>> ---
>>>>  arch/arm/mach-omap2/mux.h |    2 ++
>>>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
>>>> index e09c5d2..02a1b53 100644
>>>> --- a/arch/arm/mach-omap2/mux.h
>>>> +++ b/arch/arm/mach-omap2/mux.h
>>>> @@ -37,6 +37,8 @@
>>>>
>>>>  /* Active pin states */
>>>>  #define OMAP_PIN_OUTPUT                      0
>>>> +#define OMAP_PIN_OUTPUT_PULLUP               (OMAP_PULL_ENA | OMAP_PULL_UP)
>>>> +#define OMAP_PIN_OUTPUT_PULLDOWN     OMAP_PULL_ENA
>>>>  #define OMAP_PIN_INPUT                       OMAP_INPUT_EN
>>>>  #define OMAP_PIN_INPUT_PULLUP                (OMAP_PULL_ENA | OMAP_INPUT_EN \
>>>>                                               | OMAP_PULL_UP)
>>> Hmm, isn't this same as configuring as GPIO with up or
>>> down value?
>>>
>>> Or is there's some need doing it with mux only? Like
>>> power savings?
>> This is intended for dedicated pins rather than GPIO. Actually, I've
>> met only one till now, the HSUSB0_STP.
> 
> Hmm, are you sure you need the OMAP_PIN_OUTPUT_PULLUP for HSUSB0_STP?
> 
> AFAIK, it's not needed for other boards. I believe the STP should be
> down until the MUSB signals STP and pulls it up briefly. Might be
> worth checking.

Well, quick grep on HSUSB0_STP in U-Boot shows that all omap3 boards have
MUX_VAL(CP(HSUSB0_STP),         (IDIS | PTU | EN  | M0)) /*HSUSB0_STP*/
i.e pin is OUTPUT_PULLUP. I'll try to check if canceling the pull-up does not
affect mUSB functionality.

>> If you define most of the mux configuration in the kernel you
>> eventually run into very long lines in the omap_board_mux array. So,
>> shortening at least some of them seems good idea to me.
> 
> Yeah nothing wrong with that, I'm just thinking back to when we added
> these mux defines originally. It seemed like the the combination of
> out and pull should be needed, and pull would only be needed for inputs.
> 
>> Take a look at my second patch ([1]) for example of what I mean :)
>>
>> [1] http://en.wikipedia.org/wiki/Wikipedia:Tools/Editing_tools
> 
> I guess this is a wrong link here to the editing tool. Our mux
> code is bloated, but should not be _that_ bloated! :)

Oops :) This is the correct one:
http://thread.gmane.org/gmane.linux.ports.arm.omap/27341
Klipper screwed me entirely :)

> Eh, let's hope we don't need to implement kernel based wiki and
> editing tools for the muxing :)


> Regards,
> 
> Tony
> 

-- 
Sincerely yours,
Mike.