From owner-freebsd-arm@FreeBSD.ORG Sun Aug 19 17:02:07 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 457E6106564A for ; Sun, 19 Aug 2012 17:02:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0055E8FC15 for ; Sun, 19 Aug 2012 17:02:06 +0000 (UTC) Received: by obbun3 with SMTP id un3so11207030obb.13 for ; Sun, 19 Aug 2012 10:02:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qf61COc06Imk6lh8ZkUCHbcwu/gEQCuS3OxBge7lJ0E=; b=ovDPgOo/glv/oRVN+teYEV3pN3sfvYRu9kgOTrXjeusBFxJH3xdalZ6CZ6XQwTBEHr YKO6qC9df8m41YMEqmaVIf+eT5SQOBh+frigO+wz9/8ZLuKXIb4uVZjlFFImY+eVo3Xq AY2oAGlR4Cz6GySl4ikEOW9morbY+KdUdw6nB93b3CWWKq3LNNU7MhG3QghKR/gF1Gwt DGYlzKTbsktQPu+2dNWarUr3mydNPR1fB+fkL+MUbfCOlL5wUEg8FeArzjSV26F43hLF EsWpGHpTtyeurHyiLnT8u+cQSTHeRNrLPylthZNc39qqzLwLAurUWA9uY+kPa4sUXLEK OUZw== Received: by 10.50.6.168 with SMTP id c8mr7455076iga.21.1345395725065; Sun, 19 Aug 2012 10:02:05 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ul4sm10445391igb.15.2012.08.19.10.02.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 10:02:04 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 19 Aug 2012 11:02:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnAGv6Vziifi3ijwVNVPzOv2/Q0k8MX6lqshO7K4grqVoHiBy3HQ07JXNlK2vYq288Dursu Cc: gonzo@freebsd.org, freebsd-arm@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 17:02:07 -0000 On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote: > On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: >=20 >>=20 >> In general, I like this code in the context of the current GPIO = framework. I've been growing dissatisfied with the current GPIO = framework, however, and some of my comments reflect that more than any = comments about this specific code. >=20 > I noticed that Linux on BeagleBone does not > simply number all pins as we do. Pins are identified by > two numbers: a unit number and a pin number. Is this in the code, or just in the FTD? On Atmel, there's a single = number from 0 to max-1 with all negative numbers being invalid. But = Atmel doesn't have proper FTD support in Linux just yet (3.5 has a good = start, and 3.6 will add the missing pinmux/pinctl stuff). > The AM3358 SoC has a couple of GPIO modules, > so this makes it pretty natural to map hardware > diagrams (which refer to "pin 13 of GPIO module 1") to > software.=20 >=20 > I agree with Warner that masks are probably a bad > idea at the framework level. >=20 > But this all may have to wait for "gpioNG". As does all the pinctl/pinmux stuff... Linux is a fair bit ahead of us = in being able to configure individual pins, groups of pins, in/out = status, termination, etc. Pinctl/mux is the biggest part of the = board/SoC support code for Atmel at the moment, so one of my plans is to = transition those ports over as soon as the FTD stuff jells on the Linux = side. Plus Linux has more GPIOish things than we do. Support for buttons that = translate to a keyboard event, support for LEDs that's better than we = have, the ability to control pin drives, interrupt control for GPIOs, = etc. Makes for a lot less code and a richer experience. Warner