From owner-freebsd-mips@FreeBSD.ORG Sat May 18 01:02:35 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2DEC0829 for ; Sat, 18 May 2013 01:02:35 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id A6330811 for ; Sat, 18 May 2013 01:02:34 +0000 (UTC) Received: from [140.242.210.2] (helo=[172.24.66.44]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UdVXS-000IzG-BV; Fri, 17 May 2013 18:02:24 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Ubiquiti EdgeRouter Lite works multi-user with -CURRENT. From: Oleksandr Tymoshenko In-Reply-To: <20130517195242.6f58064b@zeta.dino.sk> Date: Fri, 17 May 2013 18:02:19 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20130516111059.38543d57@wind.dino.sk> <20130516131642.adfae355aa3bf7767e9b56e5@ddteam.net> <20130516124248.33ae4e05@wind.dino.sk> <51952112.9010607@rewt.org.uk> <20130517192206.5db0533f@zeta.dino.sk> <634DB99C-2102-44AE-8BFD-D8D767993A13@bsdimp.com> <20130517195242.6f58064b@zeta.dino.sk> To: Milan Obuch X-Mailer: Apple Mail (2.1503) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2013-05-17, at 10:52 AM, Milan Obuch wrote: > On Fri, 17 May 2013 13:28:06 -0400, Warner Losh wrote: > >> >> On May 17, 2013, at 1:22 PM, Milan Obuch wrote: >> >>> On Thu, 16 May 2013 19:10:26 +0100, Joe Holden >>> wrote: >>> >>> [ snip ] >>> >>>>> for this quick test I used OCTEON1 kernel config with some >>>>> necessary tweaks, device gpio is commented out, maybe this will >>>>> be enough for enable octeon_gpio.c (looking at files.octeon1 it >>>>> seems to be possible). I will test it, definitely. >>>> >>>> There is only one pin exposed via gpio: >>>> >>>> root@erl1:~ # gpioctl -f /dev/gpioc0 -l -v >>>> pin 07: 0 F/D, caps: >>>> >>>> Not sure if it maps to anything usable, haven't played with it yet >>>> - the other header is EJTAG according to Cavium docs. >>> >>> I built new kernel with device gpio, something is not working - F/D >>> should mean 'factory default' aka 'reset switch', but it does not >>> sense status ot that switch. No matter whether pressed or not, >>> gpioctl still reports 0. >>> >>> Also, somehow strangely, in dmesg: >>> >>> gpio0: on ciu0 >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [pin0] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin1] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin2] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin3] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin4] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin5] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin6] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin7] output=0, invinput=0, intr=0, intr_type=level >>> [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Aleksandr Rybalko , freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 01:02:35 -0000 On 2013-05-17, at 10:52 AM, Milan Obuch wrote: > On Fri, 17 May 2013 13:28:06 -0400, Warner Losh wrote: > >> >> On May 17, 2013, at 1:22 PM, Milan Obuch wrote: >> >>> On Thu, 16 May 2013 19:10:26 +0100, Joe Holden >>> wrote: >>> >>> [ snip ] >>> >>>>> for this quick test I used OCTEON1 kernel config with some >>>>> necessary tweaks, device gpio is commented out, maybe this will >>>>> be enough for enable octeon_gpio.c (looking at files.octeon1 it >>>>> seems to be possible). I will test it, definitely. >>>> >>>> There is only one pin exposed via gpio: >>>> >>>> root@erl1:~ # gpioctl -f /dev/gpioc0 -l -v >>>> pin 07: 0 F/D, caps: >>>> >>>> Not sure if it maps to anything usable, haven't played with it yet >>>> - the other header is EJTAG according to Cavium docs. >>> >>> I built new kernel with device gpio, something is not working - F/D >>> should mean 'factory default' aka 'reset switch', but it does not >>> sense status ot that switch. No matter whether pressed or not, >>> gpioctl still reports 0. >>> >>> Also, somehow strangely, in dmesg: >>> >>> gpio0: on ciu0 >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [GIANT-LOCKED] >>> gpio0: [pin0] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin1] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin2] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin3] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin4] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin5] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin6] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin7] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin8] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin9] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin10] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin11] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin12] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin13] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin14] output=0, invinput=0, intr=0, intr_type=level >>> gpio0: [pin15] output=0, invinput=0, intr=0, intr_type=level >>> gpioc0: on gpio0 >>> gpiobus0: on gpio0 >>> >>> GIANT-LOCKED line is there 16 times, once for every one from 16 >>> pins - why? >> >> Because it isn't marked as MPSAFE? Chances are something will need to >> be done to make it mp safe though. >> >> Warner > > To be precise - why 16 times? And why 16 pins, when there is only one > switch, and only one pin is reported in gpioctl output. Each pin got its own interrupt. I believe this message is printed when bus_setup_intr is called. The discrepancy between gpioctl and kernel is explained that only some of actual pins are accessible from userland. Because some pins might be reserved as signal lines by other drivers (e.g. card detect for SD interface).