From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhou Wang Subject: Re: [PATCH v4 3/4] gpio: Add find GPIO base in increasing order Date: Wed, 17 Dec 2014 19:13:00 +0800 Message-ID: <5491653C.4040709@gmail.com> References: <1417750722-14027-1-git-send-email-wangzhou.bry@gmail.com> <1417750722-14027-4-git-send-email-wangzhou.bry@gmail.com> <548E5D34.6010206@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-pa0-f41.google.com ([209.85.220.41]:57232 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751098AbaLQLNG (ORCPT ); Wed, 17 Dec 2014 06:13:06 -0500 In-Reply-To: Sender: linux-gpio-owner@vger.kernel.org List-Id: linux-gpio@vger.kernel.org To: Alexandre Courbot Cc: Russell King , Haojian Zhuang , Wei Xu , Olof Johansson , Kevin Hilman , Arnd Bergmann , Linus Walleij , liguozhu@hisilicon.com, Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , atull@altera.com, Sebastian Hesselbarth , Sebastian Andrzej Siewior , jamie@jamieiles.com, "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-gpio@vger.kernel.org" , wangzhou1@hisilicon.com On 2014=E5=B9=B412=E6=9C=8817=E6=97=A5 11:09, Alexandre Courbot wrote: > On Mon, Dec 15, 2014 at 1:01 PM, Zhou Wang w= rote: >> On 2014=E5=B9=B412=E6=9C=8810=E6=97=A5 16:51, Alexandre Courbot wrot= e: >>> >>> On Fri, Dec 5, 2014 at 12:38 PM, Zhou Wang = wrote: >>>> >>>> In function gpiochip_find_base, base number of a GPIO controller >>>> is found in decreasing order. ARCH_NR_GPIOS is used to define from >>>> which number we begin to search for base number of a GPIO controll= er. >>>> >>>> In fact, ARCH_NR_GPIOS brings us some multiplatform problems, like= : >>>> http://www.spinics.net/lists/devicetree/msg60433.html >>>> >>>> This patch adds the support to find base number of a GPIO controll= er >>>> in increasing order. It will assign base number from 0. >>>> A new dts property called gpio-number-forward must be add to the r= elated >>>> GPIO dts nodes if you want it works well. >>> >>> >>> Global GPIO numbers are a Linux-only concept, so your property shou= ld >>> be named linux,gpio-number-forward. >>> >>> But even that way I don't think I like this idea. This just adds so= me >>> more mess to how the GPIO number space is constructed, and it is >>> already quite messy as it is. You have no guarantee over the probe >>> order of your GPIO controllers, so they may very well be probed in = a >>> different order and end up with different base numbers anytime. >>> >>> Not that this is your fault - the number namespace is broken by des= ign >>> and I don't think there is a way to fix it. The long-term solution = is >>> to stop using it by switching to the gpiod interface. >>> >>> First a few questions to understand why you need your GPIOs numbere= d >>> this way, and if you need it at all: >>> - Can't you use the gpiod interface instead so you don't need to re= ly >>> on GPIO numbers? >> >> >> Hi Alexandre, >> >> Sorry for late. Could you give me more clue about the gpiod interfac= e? Don't >> we also call gpio_request() which uses GPIO number to request a >> GPIO? > > See Documentation/gpio/consumer.txt and Documentation/gpio/board.txt. > You can obtain a GPIO descriptor without using a number by calling > gpiod_get(). Prior to that, individual GPIOs need to be bound to > devices and functions using either DT (preferred) or the platform > interface. The old integer-based GPIO interface is considered > deprecated, although still widely used. But new code should rely > exclusively on gpiod, and we encourage people to convert existing cod= e > to it too. > Hi Alexandre, Thanks a lot for your explanation!! >> >>> - Do you plan to use the sysfs interface? If so then we are screwed= , >>> because there is no way to use it without using global GPIO numbers= =2E >> >> >> I am now enabling GPIO in Hip04-d01. Maybe, I can just use >> the default ARCH_NR_GPIOS, then users can manage GPIO through sysfs. >> However if so, GPIO 0~127 will be mapped to GPIO 384~511. > > Yeah, I know that's not ideal. As a workaround, users can maybe > identify the right gpiochip by parsing /sys/class/gpio/gpiochip* and > comparing the "label" node. Once the right chip is found, its "base" > entry gives the base GPIO number which can be used to export the > desired GPIO. > > We are also taking steps to come with a better sysfs interface. I wil= l > keep you in the loop. > Thanks. I'd like to keep an eye on this. Regard, Zhou >> >>> This is something we should/will fix with named exported GPIOs, but= we >>> are not here yet. >>> >>> As to how we can solve your problem: if you must use GPIO integers >>> (because you need to use the sysfs interface for instance), and nee= d >>> them affected consistently, the only way I can think of is to >>> introduce a "linux,gpio-base" property that will set gpiochip->base= to >>> a fixed number. It still kind of sucks, but at least it will enforc= e >> >> >> Thanks for your suggestion. But setting "linux,gpio-base" will bring >> gpio base implementation specific, and in face there is no place to = gain >> this gpio base info, not appropriate both in gpio arch code and dwap= b >> code. > > Yeah, besides this property did not receive a warm reception. So my > suggestion for now is to workaround the issue using the technique > described above, until we come with a better sysfs interface that doe= s > not rely on GPIO numbers. Sorry for that inconvenience. > -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html