Date: Fri, 17 May 2013 18:02:19 -0700 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: Milan Obuch <freebsd-mips@dino.sk> Cc: Aleksandr Rybalko <ray@ddteam.net>, freebsd-mips@freebsd.org Subject: Re: Ubiquiti EdgeRouter Lite works multi-user with -CURRENT. Message-ID: <F8B8DF25-66EF-4C72-A507-AAEA9BE75036@bluezbox.com> In-Reply-To: <20130517195242.6f58064b@zeta.dino.sk> References: <CACVs6=_UHMvo6DSyXzvXxJ0eCcSsC%2Bk3yZ42ia5TGzgHduT2zA@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-05-17, at 10:52 AM, Milan Obuch <freebsd-mips@dino.sk> wrote: > On Fri, 17 May 2013 13:28:06 -0400, Warner Losh <imp@bsdimp.com> wrote: > >> >> On May 17, 2013, at 1:22 PM, Milan Obuch wrote: >> >>> On Thu, 16 May 2013 19:10:26 +0100, Joe Holden <lists@rewt.org.uk> >>> 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<IN>, caps:<IN,OUT> >>>> >>>> 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: <Cavium Octeon GPIO driver> 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: <GPIO controller> on gpio0 >>> gpiobus0: <GPIO bus> 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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F8B8DF25-66EF-4C72-A507-AAEA9BE75036>