From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 7 06:41:40 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CCD01F0; Fri, 7 Nov 2014 06:41:40 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33021FE3; Fri, 7 Nov 2014 06:41:37 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NEN00KRCP8OAU50@st11p02mm-asmtp001.mac.com>; Fri, 07 Nov 2014 06:41:15 +0000 (GMT) From: Rui Paulo Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Subject: libgpio Message-id: Date: Thu, 06 Nov 2014 22:41:12 -0800 To: embedded@freebsd.org, arm@freebsd.org MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-11-07_04:2014-11-07,2014-11-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411070063 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 06:41:40 -0000 Hi, Some time ago, I wrote a gpio library as a way to interact with the = kernel gpio driver in a more sensible way (hiding the details of opening = a /dev file, handling all the ioctls, etc.). Here's the project code: https://bitbucket.org/rpaulo/libgpio/src Here's the header file: = https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06= bbade8d/libgpio.h?at=3Ddefault It looks like some people started using the library and I was wondering = if it would be a good candidate for the base system. I would rewrite = gpioctl to use it and I'm open to changing the library API. Any comments? -- Rui Paulo From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 7 07:49:47 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 868296B0; Fri, 7 Nov 2014 07:49:47 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60B18875; Fri, 7 Nov 2014 07:49:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=xNSuxj3M3cNgwnq1eA7Vl7BE/hzTSnx+LwltMoYBs7I=; b=sytGKNRtFkk224wgDy+FpfFjO3svyy7cJhEi69k/6kyJ3tB69XrpIYT2MdX8YE5OAFDk8F/wlJu31bcixfL2zAUIVNViAAWcibQVhjG/aLC31p2Xdya15vcLxWFV1xt5wscPBLP9/0CKEvUgDN1AIVLlwAMNkRndCC2LMJc10Fk=; Received: from [182.10.35.123] (port=28832 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.82) (envelope-from ) id 1XmeIj-001R94-M9; Fri, 07 Nov 2014 00:49:46 -0700 Date: Fri, 7 Nov 2014 15:49:41 +0800 From: Erich Dollansky To: Rui Paulo Subject: Re: libgpio Message-ID: <20141107154941.3694a9c9@X220.alogt.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: arm@freebsd.org, embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 07:49:47 -0000 Hi, On Thu, 06 Nov 2014 22:41:12 -0800 Rui Paulo wrote: > Some time ago, I wrote a gpio library as a way to interact with the > kernel gpio driver in a more sensible way (hiding the details of > opening a /dev file, handling all the ioctls, etc.). > > Here's the project code: > > https://bitbucket.org/rpaulo/libgpio/src > > Here's the header file: > > https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06bbade8d/libgpio.h?at=default > > It looks like some people started using the library and I was I am one of them. > wondering if it would be a good candidate for the base system. I It would. > would rewrite gpioctl to use it and I'm open to changing the library > API. > > Any comments? The only thing I would really change is to add functions which include the opening and closing of the port. With other words, the application only calls something like gpio_pin_write (Name, Pin, value) or gpio_pin_write (Pin, value) and gpio_pin_write opens and closes the device. Plus a function to set the device name to be used for all later calls. Erich From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 7 11:24:34 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9C5375A; Fri, 7 Nov 2014 11:24:34 +0000 (UTC) Received: from mx0.deglitch.com (unknown [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 745CC1D9; Fri, 7 Nov 2014 11:24:34 +0000 (UTC) Received: from [192.168.11.2] (unknown [98.248.95.7]) by mx0.deglitch.com (Postfix) with ESMTPSA id A67708FC27; Fri, 7 Nov 2014 15:24:21 +0400 (MSK) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: libgpio From: Stanislav Sedov In-Reply-To: Date: Fri, 7 Nov 2014 03:24:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2F8338D7-083E-4C3A-84A4-C197D071CA24@freebsd.org> References: To: Rui Paulo X-Mailer: Apple Mail (2.1990.1) Cc: arm@freebsd.org, embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 11:24:34 -0000 > On Nov 6, 2014, at 10:41 PM, Rui Paulo wrote: >=20 > Hi, >=20 > Some time ago, I wrote a gpio library as a way to interact with the = kernel gpio driver in a more sensible way (hiding the details of opening = a /dev file, handling all the ioctls, etc.). >=20 > Here's the project code: >=20 > https://bitbucket.org/rpaulo/libgpio/src >=20 > Here's the header file: >=20 > = https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06= bbade8d/libgpio.h?at=3Ddefault >=20 > It looks like some people started using the library and I was = wondering if it would be a good candidate for the base system. I would = rewrite gpioctl to use it and I'm open to changing the library API. >=20 > Any comments? In my opinion it is an excellent idea to import the library into the base system. It is really useful and will facilitate 3rd party applications development. I=E2=80=99d say go for it. -- ST4096-RIPE From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 7 14:38:29 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 261E1686; Fri, 7 Nov 2014 14:38:29 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 194E2CCE; Fri, 7 Nov 2014 14:38:27 +0000 (UTC) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.8/8.14.8) with ESMTP id sA7Eb9bs042651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Nov 2014 22:37:10 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.8/8.14.8/Submit) id sA7Eb9TR042650; Fri, 7 Nov 2014 22:37:09 +0800 (CST) (envelope-from kevlo) Date: Fri, 7 Nov 2014 22:37:09 +0800 From: Kevin Lo To: Stanislav Sedov Subject: Re: libgpio Message-ID: <20141107143709.GA42643@ns.kevlo.org> References: <2F8338D7-083E-4C3A-84A4-C197D071CA24@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2F8338D7-083E-4C3A-84A4-C197D071CA24@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: arm@freebsd.org, embedded@freebsd.org, Rui Paulo X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 14:38:29 -0000 On Fri, Nov 07, 2014 at 03:24:16AM -0800, Stanislav Sedov wrote: > > > > On Nov 6, 2014, at 10:41 PM, Rui Paulo wrote: > > > > Hi, > > > > Some time ago, I wrote a gpio library as a way to interact with the kernel gpio driver in a more sensible way (hiding the details of opening a /dev file, handling all the ioctls, etc.). > > > > Here's the project code: > > > > https://bitbucket.org/rpaulo/libgpio/src > > > > Here's the header file: > > > > https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06bbade8d/libgpio.h?at=default > > > > It looks like some people started using the library and I was wondering if it would be a good candidate for the base system. I would rewrite gpioctl to use it and I'm open to changing the library API. > > > > Any comments? > > In my opinion it is an excellent idea to import the library into > the base system. It is really useful and will facilitate 3rd > party applications development. Indeed. I've used libgpio for one of my projects. > I’d say go for it. +1 :-) > -- > ST4096-RIPE Kevin From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 7 15:51:43 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12862B83 for ; Fri, 7 Nov 2014 15:51:43 +0000 (UTC) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE44C87B for ; Fri, 7 Nov 2014 15:51:42 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id tr6so5456381ieb.0 for ; Fri, 07 Nov 2014 07:51:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=khTZ/wQPe6JVGuwnEovKV2pg8VMtN14KCQId0C2EBq8=; b=eWEcScNTnOahUy+SzROkPKVqfxwqaJD7Vr475PufB1Dsdl8W0Era3dTTSA2rJ85Rr7 QTHGZTC6wvz/T0++JII7FWufejwOPxT8QhSJUVMAy3ym8KJ2xUxWzo/aBljf9Lr/yhZe rxJ9/ruqbIhlDrCpI9UgwM/8BWhNLtQdSBJNEyWUb7uFLoxloOUHnypZaMqDTiogVAEp 2JHCh/bdcTqkoXpPssbkm2bWVJdZRnY/AblDAJmkNZEIGkb75MRTIKKejH+VajyG/rdU 4PSfRJi0KB49B4zw/oUaGHfdGe4zmvp2sskAkdxDEWA5NrGfuTOiZtqxDmJBmC4xrFON PsAA== X-Gm-Message-State: ALoCoQkoebobaZwZ+O9EjCpXInshrk3/6STZNhvbkTbWnGjXEUWpncdsqPbADyqdCCdLLxjuKKfu X-Received: by 10.50.43.197 with SMTP id y5mr4680485igl.33.1415375073961; Fri, 07 Nov 2014 07:44:33 -0800 (PST) Received: from bsdimp.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id n29sm4407815ioe.19.2014.11.07.07.44.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 07:44:33 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_E873F49E-869E-44FD-8979-473D22DE02FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: libgpio From: Warner Losh In-Reply-To: Date: Fri, 7 Nov 2014 08:44:30 -0700 Message-Id: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> References: To: Rui Paulo X-Mailer: Apple Mail (2.1878.6) Cc: arm@freebsd.org, embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 15:51:43 -0000 --Apple-Mail=_E873F49E-869E-44FD-8979-473D22DE02FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 6, 2014, at 11:41 PM, Rui Paulo wrote: > Hi, >=20 > Some time ago, I wrote a gpio library as a way to interact with the = kernel gpio driver in a more sensible way (hiding the details of opening = a /dev file, handling all the ioctls, etc.). >=20 > Here's the project code: >=20 > https://bitbucket.org/rpaulo/libgpio/src >=20 > Here's the header file: >=20 > = https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06= bbade8d/libgpio.h?at=3Ddefault >=20 > It looks like some people started using the library and I was = wondering if it would be a good candidate for the base system. I would = rewrite gpioctl to use it and I'm open to changing the library API. >=20 > Any comments? I generally like it. Here=92s some suggestions, though many may be hard = given that our gpio interface is a bit weak. First, there=92s no way to set multiple pins at the same time. That=92s = likely a reflection of our GPIO system, I know, but it is a deficiency. = Fortunately, most devices can tolerate multiple pins changing at = different times before a =91clock=92 or =91enable=92 pin forces them to = latch their state. What the heck is g_caps? There=92s nothing at all to describe it. Not = even an indirection to look at sys/gpio.h For systems that have multiple GPIO devices (some have a few hundred I/O = lines that can be addressed), how do you handle that? Do you just kinda have to know these details? There=92s no facilities for interrupts (usually you=92d like to say = =93wait for this line to change and let me know=94). I know that the = Atmel gpio stuff did this, but I don=92t think that made it into the = generalization that was later done. I=92m not sure that I like the gpio_pin_* helper functions causing the = thing to change, rather than operating on a gpio_config_t. But since you = don=92t normally change a bunch at a time, that=92s not so bad. Finally a question: What does Linux do here? Is there a standard = interface that we could use to leverage off applications written for = Linux? Perhaps beyond the scope of what you=92re trying to do, but any = discussion about pushing things into the base should ask the question = =93Is this the right, most useful interface?=94 Warner --Apple-Mail=_E873F49E-869E-44FD-8979-473D22DE02FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUXOjeAAoJEGwc0Sh9sBEA1RoP/2piAIsGxJ32VaI2x3Bj5p2A hzg8VpRsYSdJmLfaHbcVoSWY0h/HAJiKqSIvEnFE+1D97s91nNU7VhiYSayvGc6R NRKfZqugAzPSZUDACx6dY6huYpva4JlVdDHnQgoG6Wxdlcy565NlJVXTLuu5yeB4 OzQzX7upJUNUckFIWReTJmWAwYuGMQqSHQmWBEW0Hrg/94zemaCBXpekb4rOyiOx cVjvxr204KWfCk5iUVmo/MIKPOwMSBschUx+oyQQLAaE2ROnPQzYwmHKBN16NaMG SuzaO9TNKerGJxRaMGc5KyRAcprJ4C2I6A0HQUCZEcE0/d59D14FGi3zAqHffXCp qmYN7hmWBoYlb2ctlKhDcWmB2QrZ4z6V0E0ZI2RAkeoR2bmFfNmmbeUUWR8IjeRq roKjJfJj+Zvk52Du9OoNLPXd+YM6MdZCYQumbRRufVdK/+zKUgseGZzqwa8l+ivt knXVDPUa71v1703iHz1oFknuc2fpnPogKZFH2KW/LfRAXDtMpFtqYxd0UcCJgyZR 0rFKiwjKyZPu0X9lnYLbL98DYmVhB6eKOdLXQIudLs+QCuc9FyEgPTU6o1jjb+lb Io/+DTwO9tKrO9WFrrIoQwA1qTp7Y+ukG8/4VivcQTPmJvhhGcQ+IlT/Xa6j16vh eQrsQLn3nuJC4VxxBgQg =7WX+ -----END PGP SIGNATURE----- --Apple-Mail=_E873F49E-869E-44FD-8979-473D22DE02FD-- From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 7 16:33:35 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75A6EC3D; Fri, 7 Nov 2014 16:33:35 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AC56CDF; Fri, 7 Nov 2014 16:33:35 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id n3so5129803wiv.0 for ; Fri, 07 Nov 2014 08:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=nPebHxOI+7J+V/qHpCi0rWTmwQk+G36U05NHYj5gXRE=; b=G32om1ZoPYROi0v/LgF78S/xseOc8cTEiHwZmDxg7kENh5+LFH+4IDcPvklaWG4pin HuORDuq9HBkBmzq3KPkADu7LCR4jKHOs9bo7qaIJ1Svxq1r8B0ROfKzI4hcUO1A0DO7H LK+TdOKpXFLvnf4Zw6bo7eGWiJT2iayFgad4DeMdIWczD5oepbGoL4pWod7E8YB9OcTS 71UK01opBWy9t3Eflh05rb3PZ++5sBP+x0j7xuodSvTQSgPk3QlPGmLI9+aYoGgkUKWt yT7y+WdUvvhbVYaABcq86VSwq4cBz6J8E/JLQuILcK7RtI9Dkp1utNAxAV1U1HGR3IlA e+YQ== MIME-Version: 1.0 X-Received: by 10.180.188.41 with SMTP id fx9mr6445118wic.59.1415378013470; Fri, 07 Nov 2014 08:33:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 7 Nov 2014 08:33:33 -0800 (PST) In-Reply-To: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> References: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> Date: Fri, 7 Nov 2014 08:33:33 -0800 X-Google-Sender-Auth: fyRA3o2ytBd428oP2CtZj4ml5PE Message-ID: Subject: Re: libgpio From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" , Rui Paulo X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 16:33:35 -0000 Hi, Yes, it'd be nice to (later) add an API call that takes multiple pin updates (and reads multiple pin updates.) That way higher speed, time critical stuff can be done for drivers that grow this feature and can do batched/timestamped GPIO events. -adrian On 7 November 2014 07:44, Warner Losh wrote: > > On Nov 6, 2014, at 11:41 PM, Rui Paulo wrote: > >> Hi, >> >> Some time ago, I wrote a gpio library as a way to interact with the kern= el gpio driver in a more sensible way (hiding the details of opening a /dev= file, handling all the ioctls, etc.). >> >> Here's the project code: >> >> https://bitbucket.org/rpaulo/libgpio/src >> >> Here's the header file: >> >> https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf= 667a5c06bbade8d/libgpio.h?at=3Ddefault >> >> It looks like some people started using the library and I was wondering = if it would be a good candidate for the base system. I would rewrite gpioc= tl to use it and I'm open to changing the library API. >> >> Any comments? > > I generally like it. Here=E2=80=99s some suggestions, though many may be = hard given that our gpio interface is a bit weak. > > First, there=E2=80=99s no way to set multiple pins at the same time. That= =E2=80=99s likely a reflection of our GPIO system, I know, but it is a defi= ciency. Fortunately, most devices can tolerate multiple pins changing at di= fferent times before a =E2=80=98clock=E2=80=99 or =E2=80=98enable=E2=80=99 = pin forces them to latch their state. > > What the heck is g_caps? There=E2=80=99s nothing at all to describe it. N= ot even an indirection to look at sys/gpio.h > > For systems that have multiple GPIO devices (some have a few hundred I/O = lines that can be addressed), how > do you handle that? Do you just kinda have to know these details? > > There=E2=80=99s no facilities for interrupts (usually you=E2=80=99d like = to say =E2=80=9Cwait for this line to change and let me know=E2=80=9D). I k= now that the Atmel gpio stuff did this, but I don=E2=80=99t think that made= it into the generalization that was later done. > > I=E2=80=99m not sure that I like the gpio_pin_* helper functions causing = the thing to change, rather than operating on a gpio_config_t. But since yo= u don=E2=80=99t normally change a bunch at a time, that=E2=80=99s not so ba= d. > > Finally a question: What does Linux do here? Is there a standard interfac= e that we could use to leverage off applications written for Linux? Perhaps= beyond the scope of what you=E2=80=99re trying to do, but any discussion a= bout pushing things into the base should ask the question =E2=80=9CIs this = the right, most useful interface?=E2=80=9D > > Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 7 16:57:27 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2799543D; Fri, 7 Nov 2014 16:57:27 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D98DCEEB; Fri, 7 Nov 2014 16:57:26 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xmmqi-000CSR-Vz; Fri, 07 Nov 2014 16:57:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sA7GvNWh001353; Fri, 7 Nov 2014 09:57:23 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+dta4syf2PtEywCHtMdSqy X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: libgpio From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> Content-Type: text/plain; charset="windows-1251" Date: Fri, 07 Nov 2014 09:57:23 -0700 Message-ID: <1415379443.1200.215.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sA7GvNWh001353 Cc: "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" , Rui Paulo X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 16:57:27 -0000 On Fri, 2014-11-07 at 08:33 -0800, Adrian Chadd wrote: > Hi, >=20 > Yes, it'd be nice to (later) add an API call that takes multiple pin > updates (and reads multiple pin updates.) That way higher speed, time > critical stuff can be done for drivers that grow this feature and can > do batched/timestamped GPIO events. >=20 >=20 >=20 > -adrian >=20 mixed bottom/top posting. grrrr. comments below, where they belong. >=20 > On 7 November 2014 07:44, Warner Losh wrote: > > > > On Nov 6, 2014, at 11:41 PM, Rui Paulo wrote: > > > >> Hi, > >> > >> Some time ago, I wrote a gpio library as a way to interact with the = kernel gpio driver in a more sensible way (hiding the details of opening = a /dev file, handling all the ioctls, etc.). > >> > >> Here's the project code: > >> > >> https://bitbucket.org/rpaulo/libgpio/src > >> > >> Here's the header file: > >> > >> https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e1= 96cf667a5c06bbade8d/libgpio.h?at=3Ddefault > >> > >> It looks like some people started using the library and I was wonder= ing if it would be a good candidate for the base system. I would rewrite= gpioctl to use it and I'm open to changing the library API. > >> > >> Any comments? > > > > I generally like it. Here=92s some suggestions, though many may be ha= rd given that our gpio interface is a bit weak. > > > > First, there=92s no way to set multiple pins at the same time. That=92= s likely a reflection of our GPIO system, I know, but it is a deficiency.= Fortunately, most devices can tolerate multiple pins changing at differe= nt times before a =91clock=92 or =91enable=92 pin forces them to latch th= eir state. > > > > What the heck is g_caps? There=92s nothing at all to describe it. Not= even an indirection to look at sys/gpio.h > > > > For systems that have multiple GPIO devices (some have a few hundred = I/O lines that can be addressed), how > > do you handle that? Do you just kinda have to know these details? > > > > There=92s no facilities for interrupts (usually you=92d like to say =93= wait for this line to change and let me know=94). I know that the Atmel g= pio stuff did this, but I don=92t think that made it into the generalizat= ion that was later done. > > > > I=92m not sure that I like the gpio_pin_* helper functions causing th= e thing to change, rather than operating on a gpio_config_t. But since yo= u don=92t normally change a bunch at a time, that=92s not so bad. > > > > Finally a question: What does Linux do here? Is there a standard inte= rface that we could use to leverage off applications written for Linux? P= erhaps beyond the scope of what you=92re trying to do, but any discussion= about pushing things into the base should ask the question =93Is this th= e right, most useful interface?=94 > > > > Warner Multiple-pin read/write is really required for anything other than trivial "turn on this led" type stuff. A restriction that all the pins have to be on the same /dev/gpiocN device is fine. Routines to do simple bit-banging (so that multiple bits can be banged out with a single call) are also good to have. It's good for a driver to support an api for that at the lowest level to get reasonable speed for things like programming an fpga. (The at91 gpio drivers do this now.) -- Ian From owner-freebsd-embedded@FreeBSD.ORG Sat Nov 8 02:01:10 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 707A46B8; Sat, 8 Nov 2014 02:01:10 +0000 (UTC) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A90DBEF; Sat, 8 Nov 2014 02:01:10 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id hy10so2381025vcb.25 for ; Fri, 07 Nov 2014 18:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cBESePNobtBycFlq/KEHatA5ey5wUqNrwvlun3CBliE=; b=tlzG45NUvLIBzj7SQGcIfJN63i2CDvWbcHsFF1tfwHtxPJKiz56nLKWBp+W6wFUNHw H96/CpelcLLWtfbYf9q054PqiAVzIqQfYxOBk7JSIGFe0j5mClCuLuVBTH7ueRnNGH+c bM7BGq1gKWt3LpQGafR+i9sAVf8a6izsJnQBO/CpofOdjLt4BC4ojXggGBmgKikwrixa o20zdt+KUEjEYHWfIXa9RIR0OdUolMKFHnRoPe+7zvIiBAKLizVinz/B6hSywbue31jn CoyCCeQ+wbGUu+w5XmpaeMjIkE5eMER8mkArZCKKGLldDHC0Un8iMFrHJSuy31rsygi+ 92sg== MIME-Version: 1.0 X-Received: by 10.52.64.180 with SMTP id p20mr7587554vds.8.1415412068963; Fri, 07 Nov 2014 18:01:08 -0800 (PST) Sender: johny.mattsson@gmail.com Received: by 10.220.71.136 with HTTP; Fri, 7 Nov 2014 18:01:08 -0800 (PST) In-Reply-To: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> References: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> Date: Sat, 8 Nov 2014 13:01:08 +1100 X-Google-Sender-Auth: FIOtr6M6hryJCCCFesJbmiMzsgI Message-ID: Subject: Re: libgpio From: Johny Mattsson To: Warner Losh Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: arm@freebsd.org, embedded@freebsd.org, Rui Paulo X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 02:01:10 -0000 On 8 November 2014 02:44, Warner Losh wrote:On Nov 6, 2014, at 11:41 PM, Rui Paulo wrote: > Finally a question: What does Linux do here? Is there a standard interface > that we could use to leverage off applications written for Linux? On Linux, userspace GPIO is typically* used through the GPIO SysFS module which provides entries under /sys/class/gpio (or wherever you've mounted your sysfs). Individual pins are transferred to userspace control by writing the pin number to the "export" file, which when successful then adds a virtual directory for that GPIO line, with entries for direction, value, edge and whether it's active-low. Depending on the backing kernel driver and hardware, interrupt support may or may not be available. When available it's enabled by writing "rising", "falling" or "both" (again subject to hw/driver) to the "edge" file, and then select(2)ing on the "value" file return when said edge is triggered. Changing the output on a line is as simple as writing "0" or "1" to the "value" file. Example (drive gpio #32 high): echo 32 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio32/direction # this annoyingly/reassuringly clears this pin - i.e. cat value gives 0 echo 1 > /sys/class/gpio/gpio32/value # some time later, maybe echo 32 > /sys/class/gpio/unexport There is no support for synchronously setting multiple pins through this interface. Even if there was, it would have to be limited to within the one controller/bank. Also, if I remember the i.MX25 correctly, there was no hardware support for doing more than one line at a time anyway due to the register layout. While such a feature would be nice, I wouldn't stress too much about getting it in. At best, support for it will be sporadic depending on hardware. The (limited) documentation for GPIO SysFS on Linux, other than the source itself, can be found here: https://www.kernel.org/doc/Documentation/gpio/sysfs.txt Cheers, /Johny *) Based on personal experience at $work, and the companies we work with, doing various embedded micro and embedded Linux things. From owner-freebsd-embedded@FreeBSD.ORG Sat Nov 8 04:09:07 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEC5C9BA; Sat, 8 Nov 2014 04:09:07 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2F4D907; Sat, 8 Nov 2014 04:09:07 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NEP00707CUH2S70@st11p02mm-asmtp001.mac.com>; Sat, 08 Nov 2014 04:08:43 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-11-08_01:2014-11-07,2014-11-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411080043 Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: libgpio From: Rui Paulo In-reply-to: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> Date: Fri, 07 Nov 2014 20:08:40 -0800 Content-transfer-encoding: quoted-printable Message-id: <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> References: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1990.1) Cc: arm@freebsd.org, embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 04:09:07 -0000 On Nov 7, 2014, at 07:44, Warner Losh wrote: > I generally like it. Here=92s some suggestions, though many may be = hard given that our gpio interface is a bit weak. >=20 > First, there=92s no way to set multiple pins at the same time. That=92s = likely a reflection of our GPIO system, I know, but it is a deficiency. = Fortunately, most devices can tolerate multiple pins changing at = different times before a =91clock=92 or =91enable=92 pin forces them to = latch their state. OK; I'll work on an API that does this even if it's just a for loop = setting multiple pins to their state. > What the heck is g_caps? There=92s nothing at all to describe it. Not = even an indirection to look at sys/gpio.h It's what describes the pin: input/output/pullup/etc. I'll add some = documentation. I need to write a man page anyway. > For systems that have multiple GPIO devices (some have a few hundred = I/O lines that can be addressed), how > do you handle that? Do you just kinda have to know these details? Right now you have to work with each individually. We could change it = so that it opens all gpio devices and provides a structure that includes = all pins. > There=92s no facilities for interrupts (usually you=92d like to say = =93wait for this line to change and let me know=94). I know that the = Atmel gpio stuff did this, but I don=92t think that made it into the = generalization that was later done. There's no kernel support for it, but the library could create a thread = to poll the pin to see if it has changed. It's wasteful, but I don't = see any better way until we have GPIO interrupts. > I=92m not sure that I like the gpio_pin_* helper functions causing the = thing to change, rather than operating on a gpio_config_t. But since you = don=92t normally change a bunch at a time, that=92s not so bad. I just added those to make it easy to configure pins in one shot. > Finally a question: What does Linux do here? Is there a standard = interface that we could use to leverage off applications written for = Linux? Perhaps beyond the scope of what you=92re trying to do, but any = discussion about pushing things into the base should ask the question = =93Is this the right, most useful interface?=94 That was correctly answered by Johny. -- Rui Paulo From owner-freebsd-embedded@FreeBSD.ORG Sat Nov 8 04:37:03 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55F3258B; Sat, 8 Nov 2014 04:37:03 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15D9EC7D; Sat, 8 Nov 2014 04:37:02 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xmxlk-0003fD-QQ; Sat, 08 Nov 2014 04:37:01 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sA84axMh002540; Fri, 7 Nov 2014 21:36:59 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX185YLfL3hOH80v5go8QAP1I X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: libgpio From: Ian Lepore To: Rui Paulo In-Reply-To: <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> References: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> Content-Type: text/plain; charset="windows-1251" Date: Fri, 07 Nov 2014 21:36:58 -0700 Message-ID: <1415421418.1200.278.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sA84axMh002540 Cc: arm@freebsd.org, embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 04:37:03 -0000 On Fri, 2014-11-07 at 20:08 -0800, Rui Paulo wrote: > On Nov 7, 2014, at 07:44, Warner Losh wrote: > > I generally like it. Here=92s some suggestions, though many may be ha= rd given that our gpio interface is a bit weak. > >=20 > > First, there=92s no way to set multiple pins at the same time. That=92= s likely a reflection of our GPIO system, I know, but it is a deficiency.= Fortunately, most devices can tolerate multiple pins changing at differe= nt times before a =91clock=92 or =91enable=92 pin forces them to latch th= eir state. >=20 > OK; I'll work on an API that does this even if it's just a for loop se= tting multiple pins to their state. >=20 A loop would default the purpose of the feature. Sometimes you need to create a bus out of a collection of pins, and it only works if you can manipulate the pin states atomically as a group. If the underlying device doesn't support it, then you wouldn't be trying to do it in the first place. The current at91 gpio interface supports this in a fairly simple way, but not a way that would necessarily map to every device (it assumes 32 pins per /dev/gpiocN for example). > > What the heck is g_caps? There=92s nothing at all to describe it. Not= even an indirection to look at sys/gpio.h >=20 > It's what describes the pin: input/output/pullup/etc. I'll add some do= cumentation. I need to write a man page anyway. >=20 > > For systems that have multiple GPIO devices (some have a few hundred = I/O lines that can be addressed), how > > do you handle that? Do you just kinda have to know these details? >=20 > Right now you have to work with each individually. We could change it = so that it opens all gpio devices and provides a structure that includes = all pins. >=20 That's probably not a good idea, because gpio devices can come and go. For example, at work we have hot-pluggable expansion cards with an i2c bus that runs to each expansion slot, and there are i2c devices that provide gpio. FTDI usb<->serial chips also provide gpio pins and can come and go. I think userland software working with gpios is generally purpose- specific and targeted at a particular piece of hardware, and just knows what device and pin numbers to work with, as opposed to knowing some abstraction like "pin 147". -- Ian > > There=92s no facilities for interrupts (usually you=92d like to say =93= wait for this line to change and let me know=94). I know that the Atmel g= pio stuff did this, but I don=92t think that made it into the generalizat= ion that was later done. >=20 > There's no kernel support for it, but the library could create a thread= to poll the pin to see if it has changed. It's wasteful, but I don't se= e any better way until we have GPIO interrupts. >=20 > > I=92m not sure that I like the gpio_pin_* helper functions causing th= e thing to change, rather than operating on a gpio_config_t. But since yo= u don=92t normally change a bunch at a time, that=92s not so bad. >=20 > I just added those to make it easy to configure pins in one shot. >=20 > > Finally a question: What does Linux do here? Is there a standard inte= rface that we could use to leverage off applications written for Linux? P= erhaps beyond the scope of what you=92re trying to do, but any discussion= about pushing things into the base should ask the question =93Is this th= e right, most useful interface?=94 >=20 > That was correctly answered by Johny. >=20 > -- > Rui Paulo >=20 >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20