ISI question

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the atmel-isi compiled in to the kernel (not as a module). I'm using the latest patches from Lars Häring (see the kernel mailing lists at avr32linux.org). H/w is proprietary but based heavily on the stk1002 circuit. The ISI is connected to a FPGA generating a test pattern

I have the capture.c program from the patches page. Lars's patches supercede the ones on patches page, but didn't include an updated capture.c, so I'm hoping this program is still valid.

When I boot I see this...
Linux video capture interface: v2.00
atmel_isi atmel_isi.0: capture buffer: 962560 bytes at b0400000 (phys 0x104000)
atmel_isi atmel_isi.0: Atmel ISI V4L2 device at 0xfff02c00

After boot I see two mount points /dev/video0 and /dev/video1.
-sh-3.2# ls -l /dev/video*
crw-rw---- 1 root root 81, 0 Dec 31 2006 /dev/video0
crw-rw---- 1 root root 81, 1 Dec 31 2006 /dev/video

If I run the capture program on /dev/video0 I get a Segmentation fault. (see additional info below).

If I run the capture program on /dev/video1 I get this..

-sh-3.2# avr32_v4lcapture -d /dev/video1
Failed to open video device: No such device

Does anyone here know enough about this interface to give me some hints as to how I ought to work, and/or what I need to do to to get something sensible out of this.

---
additional info:

-sh-3.2# avr32_v4lcapture -d /dev/video0
Unable to handle kernel NULL pointer dereference at virtual address 00000000
ptbr = 90299800 pgd = 10669c66 pte = 00000000
Oops: Kernel access of bad area, sig: 11 [#1]
FRAME_POINTER chip: 0x01f:0x1e82 rev 2
Modules linked in:
PC is at __mutex_lock_slowpath+0x1e/0x68
LR is at mutex_lock+0x16/0x1c
pc : [<9010d3f6>] lr : [<9010d2f6>] Not tainted
sp : 9066fe40 r12: 902986fc r11: 00000000
r10: 9066fe40 r9 : 90298700 r8 : 9066e000
r7 : 9066fe4c r6 : 900c068c r5 : 902f72e0 r4 : 7ffa6e54
r3 : 906afe80 r2 : 902989d4 r1 : 906afe80 r0 : 906bc64c
Flags: qvNzc
Mode bits: hjmde....g
CPU Mode: Supervisor
Process: avr32_v4lcaptur [427] (task: 902f72e0 thread: 9066e000)
Stack: (0x9066fe40 to 0x90670000)
fe40: 90298700 9028ae40 05100000 9010d2f6 9066fe60 900c068c 9029853c 7ffa6e54
fe60: 900c4386 9066fe74 900c068c 9029853c 7ffa6e54 900c02e4 9066fe98 900c068c
fe80: 900c436c 7ffa6e54 906afe80 90182b20 906bac1c 906bc64c 900493fe 9066fec0
fea0: 00000000 9028ae40 7ffa6e54 906bac1c 00000000 906afe80 906bc64c 00000000
fec0: 9004679a 9066fee4 906afe80 906bac1c 7ffa6e54 00006d68 90049340 90659180
fee0: 906bc64c 90046884 9066ff08 906afe80 9066ff1c 7ffa6e54 00006d68 90254000
ff00: ffffff9c 9066e000 900468b6 9066ff6c 00000000 9066ff1c 7ffa6e54 906bc64c
ff20: 90659180 902299e0 90040054 9066ff3c 00000101 00000001 00000000 9066ff5c
ff40: 00000003 90300e48 7ffa6e54 00000000 90300e40 9066e000 9066e000 900474c4
ff60: 00000001 00000000 906afe80 900474d4 9066ff80 00000000 00000003 7ffa6e54
ff80: 90047546 9066ffa4 00008a98 7ffa6f00 7ffa6e54 00000000 000010c0 80000000
ffa0: 9066e000 90010132 00000000 00008a98 7ffa6f00 7ffa6e54 00000000 00003ef0
ffc0: 7ffa6d6c 7ffa6d50 0000c008 00000000 00006d68 00000000 00000005 7ffa6da0
ffe0: 00008a98 7ffa6f00 7ffa6e54 00000000 000010c0 00000003 000078f8 0000c008
Call trace:
[<9010d2f6>] mutex_lock+0x16/0x1c
[<900c4386>] avr32_isi_capture_open+0x1a/0xec
[<900c02e4>] video_open+0x94/0xf0
[<900493fe>] chrdev_open+0xbe/0xd0
[<9004679a>] __dentry_open+0x96/0x12c
[<90046884>] nameidata_to_filp+0x18/0x24
[<900468b6>] do_filp_open+0x26/0x2c
[<900474d4>] do_sys_open+0x30/0x8c
[<90047546>] sys_open+0xe/0x10
[<90010132>] syscall_return+0x0/0x12

Segmentation fault

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sjb wrote:
After boot I see two mount points /dev/video0 and /dev/video1.
-sh-3.2# ls -l /dev/video*
crw-rw---- 1 root root 81, 0 Dec 31 2006 /dev/video0
crw-rw---- 1 root root 81, 1 Dec 31 2006 /dev/video
I don't see video0 and video1, I see video and video0. Or did you drop a character?
sjb wrote:
If I run the capture program on /dev/video0 I get a Segmentation fault. (see additional info below).
Yea this is an in-kernel segfault, i.e. it's in the atmel-isi driver not the capture program. As such it's a) nasty and b) best reported to kernel@avr32linux.org, probably explicitly CC'ing Lars.

Thx,
-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, yes I did drop the last character of the copy and paste- it was a '1' (I keep doing this in Linux and I sometimes forget to check).

Okay, I post to avr32linux.

It's just that other here seemed to have something working with the ISI.

Last Edited: Tue. Mar 11, 2008 - 02:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah I've seen things working too, though what ever may be different about your case, it shouldn't be causing the kernel to esplode; there's a definite bug in the code, not just the setup :).

I don't know how much review the latest version of Lars' patch has seen, I didn't notice anything fly by on the list. The first one had some locking issues; I guess at least one of them remains!

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Um, so rolling back to the previous patch might be interesting, although perhaps not useful for more than fault finding.

When I try with /dev/video1 is seems to fail at the open(). Why would open return No such device when it's clearly there?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The device /file/ is indeed there, not necessarily a device.

There may be another bug in the driver which prevents the open.

Or, more likely, given that there is only one device registered at startup (atmel_isi.0) it surprises me that there are these 2 device files there. Maybe a bug in your startup scripts. How do those device files get created?

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my postcore_initcall routine I'm simply doing...

at32_add_device_isi(0);

Without this line I see no /dev/video* device files (there are supposed to be two, according two, one for capture and the other for streaming)

The driver is compiled in, not a module, and I run /sbin/mdev -s during init.

However, I think the problem may be due to not having a camera registered. I was expecting to be able to open the /dev/video* device files even without a camera, but perhaps this is a bad assumption. I try again with my camera driver (it's just not that robust yet).

UPDATE:
I've now added my camera driver back in and I get the same problem with opening /dev/video1 (this is the 'capture' device)

The only change is that I now also get a near identical Segmentation fault with /dev/video1 (this is the 'streaming' device).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(Any chance you can attach a copy of the driver patch you're using? The ones on the archive have been scrubbed and I don't have them in my mail history any more :) )

From the bit of patch I can get, in the open routine:

> +	if (!isi->camera) {
> +		ret = -ENODEV;
> +		isi->camera = avr32_isi_grab_camera(isi);
> +		if (!isi->camera)
> +			goto out;

So I'm guessing that's what triggers there, though you said it happens even with a camera driver? Maybe some printk() action around there will help out a bit, making sure your camera is correctly registered :-).

The big oops stems from

> +	struct video_device *vdev = video_devdata(file);
> +	struct atmel_isi *isi = to_atmel_isi(vdev);
...
> +	mutex_lock(&isi->mutex);

which seems to indicate that the video info was not correctly attached to both device files. In the first version of the patch (circa December 07) the return code from the first registration wasn't checked. If you're running that patch can you add some error checking on the video_register_device() calls in avr32_isi_probe()?

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Squidgit,

I've attached Lars's patch.

You were right about where to look. The to_atmel_isi() macro was returning the wrong pointer value. I'm just testing a fix now.

Lars also recommended disabling the streaming interface. I think adding the streaming is what cause the to_atmel_isi() to break. I'm going to be working on a streaming solution as soon as I get the capture to work, so this might influence how I implement the capture fix - but I'll try to post a fix here when I have it running and tested - or/and when I hit the next problem :)

.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm getting the same problem. Where did you disable the streaming interface? What does the driver do for you when you have no camera attached? (I still need to write my driver but need to know everything works fine so far)