Date: Sun, 19 Aug 2012 11:02:02 -0600 From: Warner Losh <imp@bsdimp.com> To: Tim Kientzle <tim@kientzle.com> Cc: gonzo@freebsd.org, freebsd-arm@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch Message-ID: <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> In-Reply-To: <E7C5ED5C-7120-4B69-9146-D9CC7A8E14C2@kientzle.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> <E7C5ED5C-7120-4B69-9146-D9CC7A8E14C2@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7E6C76BE-1D3F-40E4-BFE3-DC88715C234C>