Tony Lindgren wrote: > * Mike Rapoport <mike.rapop...@gmail.com> [091130 13:57]: >> On Mon, Nov 30, 2009 at 11:12 PM, Tony Lindgren <t...@atomide.com> wrote: >>> * Mike Rapoport <m...@compulab.co.il> [091129 00:10]: >>>> Signed-off-by: Mike Rapoport <m...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
