[pxc] A couple issues.

[Michael Belisle]

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/