From: Florian Fainelli <florian.fainelli@telecomint.eu>
To: Ingo Molnar <mingo@elte.hu>
Cc: Michael Buesch <mb@bu3sch.de>,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
linux-kernel <linux-kernel@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [PATCH RFC] x86: Add user configurable GPIO-lib support
Date: Tue, 1 Jul 2008 14:55:55 +0200 [thread overview]
Message-ID: <200807011455.56273.florian.fainelli@telecomint.eu> (raw)
In-Reply-To: <20080701110436.GA32365@elte.hu>
Hello Michael, Ingo,
Le Tuesday 01 July 2008 13:04:37 Ingo Molnar, vous avez écrit :
> * Michael Buesch <mb@bu3sch.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
------------------------------
next prev parent reply other threads:[~2008-07-01 12:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-01 10:49 Michael Buesch
2008-07-01 11:04 ` Ingo Molnar
2008-07-01 11:13 ` Michael Buesch
2008-07-01 11:19 ` Ingo Molnar
2008-07-01 11:27 ` Michael Buesch
2008-07-01 23:05 ` Michael Buesch
2008-07-01 12:55 ` Florian Fainelli [this message]
2008-07-01 14:26 ` Ingo Molnar
2008-07-02 2:57 David Brownell
2008-07-02 9:40 ` Michael Buesch
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=200807011455.56273.florian.fainelli@telecomint.eu \
--to=florian.fainelli@telecomint.eu \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mb@bu3sch.de \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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
all inboxes | Powered by JetHome®