[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdaOSSA8PuTSQ4utp9JHKbBiz+iWfuPn=2WyojZxsR5a3A@mail.gmail.com>
Date: Tue, 17 Apr 2012 08:47:17 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Diego Elio Pettenò <flameeyes@...meeyes.eu>
Cc: Grant Likely <grant.likely@...retlab.ca>,
guillaume ligneul <guillaume.ligneul@...lis.com>,
Linus Walleij <linus.walleij@...ricsson.com>,
Guenter Roeck <guenter.roeck@...csson.com>,
Jean Delvare <khali@...ux-fr.org>,
Wim Van Sebroeck <wim@...ana.be>,
Denis Turischev <denis@...pulab.co.il>,
linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org
Subject: Re: [RFC] IT87xx GPIO and other drivers
On Mon, Apr 16, 2012 at 9:51 PM, Diego Elio Pettenò
<flameeyes@...meeyes.eu> wrote:
> The GPIO pins on most of the it87xx chips are also multi-function, and
> _should not_ be user-visible, but for some of them it might make sense
> to (for instance it should be possible to drive some of the LEDs on
> it8728f-based motherboards by replacing the functions of some PINs to GPIO).
>
> For what I can tell, it should probably be a good idea to have something
> along these lines, but I'm _not_ a driver expert:
>
> - mfd-it87xx: a platform driver, which probes the superio to check it
> to be an it87xx chip, and then reserve resources for the other drivers;
> - hwmon/it87: no longer probes autonomously for which chip it is, and
> where it is;
> - it87_wdt: ibidem;
> - it8712_wdt: no clue about it, but I guess the same;
> - gpio-it87: ibidem again;
> - pinctrl-it87: abstracts support for the various pin-choice registers;
> - led-it87: possibly to drive the power/network/hdd leds, akin to what
> happens with some laptops, and embedded systems.
I would suggest merging gpio-it87 and pinctrl-it87 into one driver
in drivers/pinctrl-it87.c. I don't know for sure however, since it depends
on hardware: usually these is a tight dependence between GPIO and
pinctrl (IIRC this was the case with SuperIO), and then it often makes
a lot of sense to create a composite driver, in order to just have one
state container (cookie) to pass around in the functions, and to remap
a register range only once.
The concept is explained in my pinctrl talk on a high level:
http://www.df.lth.se/~triad/papers/pincontrol.pdf
Yours,
Linus Walleij
--
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