Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Oct 2007 10:04:58 +0300
From:      Achilleas Mantzios <achill@matrix.gatewaynet.com>
To:        John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Cc:        freebsd-multimedia@freebsd.org, Mark Tinguely <tinguely@casselton.net>
Subject:   Re: bktr and GPIO
Message-ID:  <200710290904.59350.achill@matrix.gatewaynet.com>
In-Reply-To: <20071026171936.GI39759@funkthat.com>
References:  <200710261359.l9QDxFZh088302@casselton.net> <200710261827.25933.achill@matrix.gatewaynet.com> <20071026171936.GI39759@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
=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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710290904.59350.achill>