From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 19 Jul 2012 10:39:17 +0200 From: Christian Engelmayer To: , , Subject: Re: [RFC] Configure GPIO settings via the device tree Message-ID: <20120719103917.78e01091@frequentis.com> In-Reply-To: <20120713100440.7a80e05f@frequentis.com> References: <20120713100440.7a80e05f@frequentis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: linuxppc-dev@lists.ozlabs.org, christian.engelmayer@frequentis.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hello, As there was no response to my question I assume that I see it correctly that at the moment the only 2 options for setting up GPIO configurations is either via platform-specific code by eg. platform_data or via userspace? Would there be a common use of defining GPIO configurations via a device tree and applying those settings via a generic, platform-unaware driver? Regards, Christian On Fri, 13 Jul 2012 10:04:40 +0200 Christian Engelmayer wrote: > Hello, > > I am looking for a way to configure GPIO initial settings and exports to the > userspace via Sysfs in a generic way via a device tree. > > The purpose would be to have the same features as when initializing and > exporting pins via platform code, eg. > > static struct gpio leds_gpios[] = { > { 32, GPIOF_OUT_INIT_HIGH, "Power LED" }, /* default to ON */ > { 33, GPIOF_OUT_INIT_LOW, "Green LED" }, /* default to OFF */ > { 34, GPIOF_OUT_INIT_LOW, "Red LED" }, /* default to OFF */ > { 35, GPIOF_OUT_INIT_LOW, "Blue LED" }, /* default to OFF */ > { ... }, > }; > > ,however, with no need for the kernel to know anything more about those pins > and their later handling by simple userpsace drivers than the setup information > provided in the device tree. > > This should also attack the problem of unstable GPIO numbers in the case of > daughtercards on different base boards and would help provide a defined API > to the userspace based on pin labels with the board specifics hidden in one > place in the device tree. > > Is there already a way for realizing such a scenario ? > > Regards, > Christian