From mboxrd@z Thu Jan 1 00:00:00 1970 From: stigge@antcom.de (Roland Stigge) Date: Sun, 30 Sep 2012 17:46:29 +0200 Subject: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib In-Reply-To: References: <1348780923-27428-1-git-send-email-stigge@antcom.de> <50682402.8020402@antcom.de> <506860C6.5020408@antcom.de> Message-ID: <50686955.8040503@antcom.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 30/09/12 17:19, Stijn Devriendt wrote: >> If I understand correctly, it's a violation (single-value should hold >> for read and write). >> >> To solve it, I have the following in mind: /sys/.../gpiogroupXXX/ >> contains files "bit0" ... "bit31" which contain a gpio number each, >> empty if "unconnected". > > Unfortunately that means you can't atomically create a group. I don't see a big advantage of having atomic create/request. Most important is set/get, isn't it? I assume the following usage pattern: * Create(request) - non atomic (maybe atomic but why not add GPIOs later?) * Set - atomic * Get - atomic * ... > It also creates a mess to keep ordering intact and to either > keep the current pin state or override it at allocation-time. Ordering should stay intact, and later add/delete operations could be possible. I meant bit0 ... bit31 in the gpio block as such: bit0 - "80" bit1 - "" (i.e. unconnected) bit2 - "85" bit3 - "2" ... bit31 - "" This scheme can support multiple gpio_chips, as discussed with Linus and JC, which of course can't always guarantee real simultaneous I/O but provide virtual I/O word access (32bit/64bit). > Rules are rules, but why make the interface overly complex when > the multi-value file is saner, cleaner and simpler? Simply because they won't (and probably shouldn't) accept it mainline. Roland From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751334Ab2I3Pqj (ORCPT ); Sun, 30 Sep 2012 11:46:39 -0400 Received: from antcom.de ([188.40.178.216]:60375 "EHLO chuck.antcom.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750878Ab2I3Pqi (ORCPT ); Sun, 30 Sep 2012 11:46:38 -0400 Message-ID: <50686955.8040503@antcom.de> Date: Sun, 30 Sep 2012 17:46:29 +0200 From: Roland Stigge Organization: ANTCOM Open Source Research and Development User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120922 Icedove/10.0.7 MIME-Version: 1.0 To: Stijn Devriendt CC: grant.likely@secretlab.ca, linus.walleij@linaro.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, w.sang@pengutronix.de, jbe@pengutronix.de, Jean-Christophe PLAGNIOL-VILLARD , bgat@billgatliff.com Subject: Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib References: <1348780923-27428-1-git-send-email-stigge@antcom.de> <50682402.8020402@antcom.de> <506860C6.5020408@antcom.de> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/09/12 17:19, Stijn Devriendt wrote: >> If I understand correctly, it's a violation (single-value should hold >> for read and write). >> >> To solve it, I have the following in mind: /sys/.../gpiogroupXXX/ >> contains files "bit0" ... "bit31" which contain a gpio number each, >> empty if "unconnected". > > Unfortunately that means you can't atomically create a group. I don't see a big advantage of having atomic create/request. Most important is set/get, isn't it? I assume the following usage pattern: * Create(request) - non atomic (maybe atomic but why not add GPIOs later?) * Set - atomic * Get - atomic * ... > It also creates a mess to keep ordering intact and to either > keep the current pin state or override it at allocation-time. Ordering should stay intact, and later add/delete operations could be possible. I meant bit0 ... bit31 in the gpio block as such: bit0 - "80" bit1 - "" (i.e. unconnected) bit2 - "85" bit3 - "2" ... bit31 - "" This scheme can support multiple gpio_chips, as discussed with Linus and JC, which of course can't always guarantee real simultaneous I/O but provide virtual I/O word access (32bit/64bit). > Rules are rules, but why make the interface overly complex when > the multi-value file is saner, cleaner and simpler? Simply because they won't (and probably shouldn't) accept it mainline. Roland