From owner-freebsd-multimedia@FreeBSD.ORG Mon Oct 29 16:48:56 2007 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89E5816A46C for ; Mon, 29 Oct 2007 16:48:56 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (host3.dynacom.ondsl.gr [62.103.35.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3498113C4A5 for ; Mon, 29 Oct 2007 16:48:54 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (localhost [127.0.0.1]) by smadev.internal.net (8.13.6/8.13.6) with ESMTP id l9T750MJ072531; Mon, 29 Oct 2007 09:05:00 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) Received: from localhost (localhost [[UNIX: localhost]]) by smadev.internal.net (8.13.6/8.13.6/Submit) id l9T74xSc072530; Mon, 29 Oct 2007 09:04:59 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) From: Achilleas Mantzios Organization: Dynacom Tankers Mgmt To: John-Mark Gurney Date: Mon, 29 Oct 2007 10:04:58 +0300 User-Agent: KMail/1.9.3 References: <200710261359.l9QDxFZh088302@casselton.net> <200710261827.25933.achill@matrix.gatewaynet.com> <20071026171936.GI39759@funkthat.com> In-Reply-To: <20071026171936.GI39759@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710290904.59350.achill@matrix.gatewaynet.com> Cc: freebsd-multimedia@freebsd.org, Mark Tinguely Subject: Re: bktr and GPIO X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2007 16:48:56 -0000 =CE=A3=CF=84=CE=B9=CF=82 =CE=A0=CE=B1=CF=81=CE=B1=CF=83=CE=BA=CE=B5=CF=85= =CE=AE 26 =CE=9F=CE=BA=CF=84=CF=8E=CE=B2=CF=81=CE=B9=CE=BF=CF=82 2007 20:19= , =CE=BF/=CE=B7 John-Mark Gurney =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5: > Achilleas Mantzios wrote this message on Fri, Oct 26, 2007 at 18:27 +0300: > > ???????? ?????????????????? 26 ?????????????????? 2007 16:59, ??/?? Mar= k=20 Tinguely ????????????: > > > (deleted information. He is interested in getting the Zoneminder > > > bktr(8) based relays to work). > > > > > > > I have some contact with the person who manufactures the cards and > > > > writes the linux drivers, and he asked me if FreeBSD has access to > > > > bt878 GPIO, and said that it would be easy if so. > > > > > > You will need to know what values need to be writen to which register > > > to enable the particular relay. In the kernel driver source program, > > > add a new ioctl() so that you can enable this feature from the user > > > program. > > > > According to Vassili Leonov of LML, > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > In relation to bits assignments on LMLBT4M and LMLBT44 cards: > > > > /* to allow access to GPIO bits for sensors input and > > alarms output > > > > GPIObit | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | > > assignment | TI | O3|INx| O2| O1|IN4|IN3|IN2|IN1| | | > > > > IN - sensor inputs, INx - sensor inputs and TI XORed together > > O1,O2,O3 - alarm outputs (relays) > > > > GPIO bits should be enabled for outpus as follows: > > > > OUT ENABLE 1 1 0 . 1 1 0 0 . 0 0 0 0 =3D 0x6C0 > > > > */ > > > > So the words are 11 bits long. > > > > > The command inside the new ioctl() will probably look roughly like: > > > > > > #ifdef OPTIONAL_READ_OLD > > > /* optionally may need to preserve some other settings */ > > > set =3D (IN#(bktr, BKTR_GPIO_@@@@) & ~mask) | set; > > > #endif > > > OUT#(bktr, BKTR_GPIO_@@@@, set); /* turn on relay "value" */ > > > > > > where > > > mask optional turn off bits > > > set enable bits > > > # is the size (B)yte, (W)ord, (L)ong > > > @@@@ is the register location (you probably will have to add a > > > define for this location into the header file). > > > > Is > > > > #define BKTR_GPIO_DMA_CTL 0x10C > > #define BKTR_GPIO_OUT_EN 0x118 > > #define BKTR_GPIO_REG_INP 0x11C > > #define BKTR_GPIO_DATA 0x200 > > > > in /usr/src/sys/dev/bktr/bktr_reg.h any relevant to the above? > > No, that is internal to the driver... > > > What to they represent? > > Why i was able to call ioctl BT848_GPIO_* on /dev/tuner0 but > > not /dev/bktr0? > > I'm not sure why.. It was the decision made by whom ever wrote > the code.. I do agree that it's a bit weird, but usually the gpio > pins are used to reset the tuner, so they figured that it was easier > for the tuner driver (which don't really exist except for in the kernel) > to have access to them than the video capture device... It seems that this decision was a wise one (for my case). Since /dev/bktr* does not allow multiprocess access, if it was done through= =20 the video driver, it would be impossible to capture video->detect motion fr= om=20 one process and at the same time from an independent process activate some= =20 bits on the GPIO to trigger an alarm. I have the zoneminder capture daemon running on /dev/bktr0, while having a= =20 perl script reading shared memory to diagnose if we are in a new alarm stat= e=20 and calling the program to deal with GPIO via /dev/tuner0. Doing it from the capture daemon would be very hard to say the least. So for me it proved a good choice! > > > A little enlightment would be great! > > You want to look in /usr/include/dev/bktr/ioctl_bt848.h at: > #define BT848_GPIO_SET_EN _IOW('x', 72, int) /* set gpio_out_en > */ #define BT848_GPIO_GET_EN _IOR('x', 73, int) /* get > gpio_out_en */ #define BT848_GPIO_SET_DATA _IOW('x', 74, int) /* > set gpio_data */ #define BT848_GPIO_GET_DATA _IOR('x', 75, int) /* > get gpio_data */ > > SET_EN sets the input/output enable bits, GET_EN gets the current bits.. > Then you can use SET_DATA/GET_DATA to change/read the data on the bits... > > If you look at: > http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/user/jmg/bktrau= /cap >ture/main.c&REV=3D27 > > You'll see how I manipulate the bits to reset the tuner... Thanx! What i did upto now regarding GPIO seemed to work perfectly. The next step is to lay my hands on the bare wires :) I am kind of optimistic about this! > > Good luck! =2D-=20 Achilleas Mantzios