[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200807011455.56273.florian.fainelli@telecomint.eu>
Date: Tue, 1 Jul 2008 14:55:55 +0200
From: Florian Fainelli <florian.fainelli@...ecomint.eu>
To: Ingo Molnar <mingo@...e.hu>
Cc: Michael Buesch <mb@...sch.de>, tglx@...utronix.de,
mingo@...hat.com, hpa@...or.com,
linux-kernel <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH RFC] x86: Add user configurable GPIO-lib support
Hello Michael, Ingo,
Le Tuesday 01 July 2008 13:04:37 Ingo Molnar, vous avez écrit :
> * Michael Buesch <mb@...sch.de> wrote:
> > So this adds user-configurable GPIO support through gpiolib on
> > subarchitectures that do not implement a GPIO implementation, yet.
> > Currently that's everything except X86_RDC321X.
The only reason RDC321x is not yet converted to using gpiolib is the small
number of actually accessible GPIOs, anyway, I will do the conversion soon.
> >
> > The advantage of this is to make it possible to use generic PCI (or
> > other bus) GPIO extention cards in standard PCs through the standard
> > GPIO API.
> >
> > If another subarch implements its own GPIO, it needs to add itself as
> > an inverted dependency to GPIO_USERSELECTION to make sure the user
> > does not enable two GPIO API implementations.
> >
> > About the asm-x86/gpio.h:
> > I'm not sure what this <gpio.h> include currently is.
> > Can somebody explain that to me? Where is this supposed
> > to include a gpio.h file from?
> >
This code is inherited from MIPS/ARM before GPIO lib, where generic assembly
headers provide prototypes for the usual GPIO functions. Boards override
those functions with their own copy of these GPIO functions.
> #ifdef CONFIG_X86_ELAN
> # define PIT_TICK_RATE 1189200 /* AMD Elan has different frequency! */
> #elif defined(CONFIG_X86_RDC321X)
> # define PIT_TICK_RATE 1041667 /* Underlying HZ for R8610 */
> #else
> # define PIT_TICK_RATE 1193182 /* Underlying HZ */
> #endif
>
> ... once that is made dynamic/quirkable we are there.
Yes, I did not have time to investigate this, and am still wondering if we can
have dynamic tick rate settings in early board setup code.
--
Cordialement, Florian Fainelli
------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists