From Michael.Belisle@asu.edu  Tue Jun  1 00:37:18 2004
From: Michael.Belisle@asu.edu (Michael Belisle)
Date: Tue Jun  1 00:37:44 2004
Subject: [pxc] A couple issues.
In-Reply-To: <20040530142319.GA11158@mail.gnudd.com>
Message-ID: <392F6F6E-B29C-11D8-9637-003065790CA8@asu.edu>


On Sunday, May 30, 2004, at 06:27 America/Phoenix, tboult wrote:

> If you do not really need the special features of the pxc driver you 
> might consider the bttv driver built into almost
> every linux distro (its part of bttv module).  I've used both but use 
> the bttv one almost exclusively now since
> the results are more portable
>
I might try that because I do not know what the extra features are.  I 
know that I need to do data acquisition concurrently with video 
capture, but I don't think I need to have complete control over the 
nature of the video capture.

On Sunday, May 30, 2004, at 07:23 America/Phoenix, Alessandro Rubini 
wrote:
> Meanwhile, I'd better not support the redhat variant.
I may switch to Debian.  I wanted to get started on research instead of getting starting on installing a new OS, so I took the computer as it was despite my desire to get rid of RedHat.

> ...
>> After configuring my kernel's memory usage to open 5MB of memory and
>> loading the module, I tried to run pxc_xgrab.  The produced video
>> image is only horizontal lines of gibberish.
>
> According to the pattern you get, you can see whether DMA takes place
> or not. If you try "cat /dev/pxc0pgm | od -t x1" you can see that. If
> no DMA happens, you'll see a repeating test string (as defined
> in allocator.c).
The following block repeats (though the first 7 numbers change).

0220000 50 35 20 20 33 32 30 20 20 32 34 30 20 32 35 35
0220020 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0220040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*

I can't tell, based on my limited knowledge of programming, whether or 
not this is the test string in allocator.c.  I took a screenshot of the window: <http://frc.asu.edu/vdisplay.gif>. The test string, which I 
think is  "**UU4321--**xyz", comes out differently when run through od 
-t x1.  The repetition seems suspicious to me, but what do I do about it?

> ...
>> 1.) Verified IRQ correlation between /proc/pci and /proc/interrupts.
>> Initially, the PXC200 was sharing an IRQ with the USB bus, and
>> didn't show up in /proc/interrupts.
> ...
> It should show up only then the device is in use (for example, try
> sleep 10000 < /dev/pxc0). And sharing should not be a problem (i.e.,
> I think it's supported fine).
>
For some reason, my version of Red Hat only lists the first device on 
an IRQ line in /proc/interrupts.  My other Red Hat machine lists all of 
the devices sharing an interrupt.  I agree that it didn't seem to be a problem that it was on a shared IRQ.

> I'm interested in whether interrupts flow in or not. Is the counter
> in /proc/interrupts increasing? (yes, avoiding a shared IRQ line is 
> good
> to this aim) -- but I suppose it does, or the read() system call will
> block.
>
The counter is increasing.

> Another idea is compiling with DEBUG=y in the environment (or "make"
> command line), and seeing in the kernel messages if something 
> interesting
> shows up.
>
Trying to run pxc_grab gives the following messages and results in the error of "device or resource busy."

pxc200: resetting
pxc200: init i2c called
pxc200: apply: set 2 to 0
pxc200: apply: set 3 to 216
pxc200: apply: set 3 to 216
pxc200: apply: set 3 to 216
pxc200: apply: set 4 to 0
pxc200: apply: set 5 to 254
pxc200: apply: set 5 to 254
pxc200: apply: set 5 to 254
pxc200: apply: set 6 to 180
pxc200: apply: set 6 to 180
pxc200: apply: set 6 to 180
pxc200: apply: set 7 to 128
pxc200: initializing MAX517 to 128
pxc200: init: video format is 0
pxc200: switching to format 0
pxc200: switched to format 1
pxc200: allocating: 2 bufs, 77824 bytes each, got 0x0fb00000
pxc200: buffer 0: 0xcd128000 0x00000000
pxc200: buffer 1: 0xca8e9000 0x00000000
pxc200: program: sync 8004 8004, i 0, incr 1
pxc200: written program 0: nextptr == 0xcd1287a4
pxc200: program: sync 8004 8004, i 0, incr 1
pxc200: written program 1: nextptr == 0xca8e97a4
pxc200: acq on: risc now at 0x0d128000
pxc200: isr 1: "present" changed
pxc200: read: wait_event
pxc200: giving buffer 0 to owner (last was 0)
pxc200: ioctl: 40107014 bffff030: nr 20, size 16, dir 1
pxc200: acq_on with a buffer active
pxc200: freeing DMA buffer

Michael J. Belisle
Flight Research Center
Department of Mechanical and Aerospace Engineering
Arizona State University
Michael.Belisle@asu.edu
http://frc.asu.edu/
From luislloret@visarcontrol.es  Thu Jun 17 18:06:12 2004
From: luislloret@visarcontrol.es (Luis Lloret)
Date: Thu Jun 17 18:07:07 2004
Subject: [pxc] Proc filesystem support for 2.4 kernel
References: <392F6F6E-B29C-11D8-9637-003065790CA8@asu.edu>
Message-ID: <000d01c45485$03735490$2217000a@VISAR>

    Hi,

    just a question about the PXC200 driver for linux:
    why is the proc filesystem support disabled out for the 2.4 kernel
release?

    Could I try to help to make it work?

    Thanks.

From rubini@gnudd.com  Thu Jun 17 18:19:26 2004
From: rubini@gnudd.com (Alessandro Rubini)
Date: Thu Jun 17 18:51:24 2004
Subject: [pxc] Proc filesystem support for 2.4 kernel
In-Reply-To: <000d01c45485$03735490$2217000a@VISAR>
References: <000d01c45485$03735490$2217000a@VISAR>
Message-ID: <20040617161926.GA4440@mail.gnudd.com>


Hello.

>     why is the proc filesystem support disabled out for the 2.4 kernel
> release?

Most likely because when I ported it to 2.4 it was different enough to
not be worth the #ifdef effort. Then I forgot about it. I'll try to
keep that in mind when I work on it, it should have been this week, but it
already slipped one or two weeks.

It's now ported to 2.6, but I couldn't test it (only compile), and I need
to integrate the new sequence support, by Francesco Chiechi. Hope to
make a numbered release soon.

/alessandro
From greis@sel.eesc.usp.br  Thu Jun 17 21:16:30 2004
From: greis@sel.eesc.usp.br (Gilson Reis)
Date: Sun Aug 29 11:07:10 2004
Subject: [pxc] help-me, please.
Message-ID: <001c01c4549f$917f0350$de00a8c0@Karmina02>

Hello, Alessandro.
    I formatted my computer and installed the Linux(Debian), kernel-source-2.4.18.
    I followed your instructions and downloaded the latest CVS snapshot at ftp.linux.it/pub/People/rubini/pxc. While I executed:

"/home/greis/pxc/pxc-snapshot-040608# make KERNELDIR=/usr/src/kernel-source-2.4.18/"

the following error occurred:

"gcc -Wall -O2 -fomit-frame-pointer -c grabtofile.c -o grabtofile.o
grabtofile.c:44: jpeglib.h: No such file or directory
make: *** [grabtofile.o] Error 1"

    I searched for the 'jpeglib.h' library in my computer and the internet and found nothing that could help.
    Please, how do I proceed?
    Thanks very much.

Gilson Reis


%%%%%%%%%%%%%%%%%%%%%%%%%
     LASI - Laborat?rio de Sistemas Inteligentes
         Departamento de Engenharia El?trica
         Escola de Engenharia de S?o Carlos
           UNIVERSIDADE DE S?O PAULO
                          SP - BRASIL
%%%%%%%%%%%%%%%%%%%%%%%%%

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux.it/pipermail/pxc/attachments/20040617/a99964dc/attachment.html
