From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18247 invoked by alias); 28 May 2010 22:06:06 -0000 Received: (qmail 18237 invoked by uid 22791); 28 May 2010 22:06:05 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from cheviot11.ncl.ac.uk (HELO cheviot11.ncl.ac.uk) (128.240.234.11) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 May 2010 22:06:01 +0000 Received: from cheviot11.ncl.ac.uk (localhost.localdomain [127.0.0.1]) by cheviot11.ncl.ac.uk (8.13.8/8.13.8) with ESMTP id o4SM5v7B017481 for ; Fri, 28 May 2010 23:05:58 +0100 Received: from exhubdb01.campus.ncl.ac.uk (exhubdb01.ncl.ac.uk [10.8.239.3]) by cheviot11.ncl.ac.uk (cheviot11.ncl.ac.uk [128.240.233.111]) envelope-from with ESMTP id m4RN5v23543162088D ret-id none; Fri, 28 May 2010 23:05:58 +0100 Received: from EXSAN01.campus.ncl.ac.uk ([10.8.239.16]) by exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Fri, 28 May 2010 23:05:58 +0100 From: Steven Clugston To: "ecos-devel@ecos.sourceware.org" Date: Fri, 28 May 2010 22:06:00 -0000 Subject: RE: Generic GPIO framework Message-ID: <4DCF6DBD3535F742BB167C528BBEE9805F4C5F49C9@EXSAN01.campus.ncl.ac.uk> References: <4BFFD7CC.4020204@intefo.ch> In-Reply-To: <4BFFD7CC.4020204@intefo.ch> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-smtpf-Report: sid=m4RN5v235431620800; tid=m4RN5v23543162088D; client=lan,relay,white,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2010-05/txt/msg00008.txt.bz2 I for one would like to see this included so I hope the maintainers see fit= to do so. This could be used to create drivers that are more generic for add-on devic= es (bit-bang buses/LCD screens) that otherwise sometimes find their way int= o HAL because pin platform specific pin macro definitions are needed somewh= ere to actually act on the hardware. A common GPIO interface could allow a = driver to be written for a device without knowing or caring exactly what th= e pin assignment will be and what HAL macros are needed to change the pin s= tates. Obviously this would need to be defined somewhere board specific ins= tead but at least then the driver code will work for more than one board. Might slight concern is that checking or changing a pin state often might i= ncur an extra stack push/pop overhead (over the HAL macros) if the get/set = functions are not inlined. Steven