Re: [Mjpeg-developer] Zoran Linux driver 64-bit support

[Klaus S. <Kla...@as...>]

Hi Bernhard,

Bernhard Praschinger wrote:
> >> But I have problems getting the driver working. I do not get a
> >> /dev/video0 device. The DC-30 is detected in some way but refuses to
> >> work. I hope that you can give me a hint how to accomplish that.
> Do you need to load any modules manual ?

No. On Debian squeeze I didn't have to load anything manually. It just
works out of the box.

> On my machine there is only the zr36067 loaded an no other modules 
> needed for the cards.

I think this is because the i2c setup is done very early in the
initialization process. If I remember correctly, the other chips on the
board aren't directly connected to the PCI bus, but they can be accessed
via the i2c bus on the zr360xx. The i2c on the card is exposed by
special registers in PCI configuration space that allow the host PC to
send and receive commands on that bus. For some reason the commands put
into to those configuration registers don't seem to do what they're
supposed to do on your machine. The error message you see actually comes
from the i2c_algo_bit module and not from the zoran driver itself.

In some cases the access to that bus is somewhat time critical and the
driver immediately performed a reset before trying to test the i2c bus
access. Maybe the capture card just hadn't enough time to settle, so
that there are unexpected disruptions from the reset procedure while the
i2c_algo_bit module tries to test if the bus functions properly.

You could try to add a short delay immediately after the call to
zr36057_restart in zoran_card.c (around line 1353) by inserting the
following line:

mdelay(1);

Additionally, you should try to get more debug output for both the
i2c_algo_bit and zr36067 modules. You can try to remove both modules and
load them again with modprobe and the parameters i2c_debug=3 for
i2c_algo_bit and debug=5 for zr36067.

> I didn't test it with a 2.6.32 kernel, I can try to do that tomorrow. I 
> did upgrade my system to opensuse 10.4 x64 2-3 months ago. I haven't 
> done any test with a zoran based card since that upgrade.

But you already had the card working on that hardware configuration
before, right?

> I did check with the original 2.6.37 Kernel used by Suse there the zoran 
> card isn't detected, and there is also no /dev/video0 device.

Ok, so at least it's certainly not a problem introduced by my patch.

> I have the same problem with the Buz.
> I have attached the output from dmesg. I hope that it tells you more 
> than it tells me. You can see in the log that the onboard radeon card 
> has also a problem with i2c.
> Could that be the cause of the problem ?
> What I don't understand is that the module i2c_piix4 is loaded. I have 
> also attached the output of lsmod.

The i2c_piix4 seems to be used as a system management bus on your
motherboard, which is something entirely different. Also the i2c bus on
your graphics card is completely separated from the bus on the zoran
chip. The drivers usually share some generic infrastructure for
enumerating available buses and attached devices, but for the zoran
cards the real work is done by the i2c_algo_bit module only.

> >> I don't know of any other tool to record from a zoran based car. A patch
> >> for lavrec would be really great.
> > Ok, I'm currently hacking something together just to make it capture
> > with a mostly fixed set of parameters. Trying to translate the existing
> > lavrec data structures to V4L2 syscalls isn't that easy, because there
> > is no one-to-one correspondence for the whole decimation settings and
> > many parameters for input and norm selection also look quite different.
> Maybe Ronald can give you any hints for that task.

With the attached version of liblavrec I already managed to capture
hardware-encoded MJPEG video, using the V4L2 interface only, on 2.6.38
with my patch and 64-bits. It's still a lot of work, because I had to
disable signal auto-detection as well as the whole software encoding and
it doesn't properly support any decimation.

It seems that there is also a problem with signal detection in the
driver with the V4L2 interface, because it always had the NO SIGNAL flag
set, no matter if the attached source actually produced any output or
not. The color detection seemed to work though, because the bit toggled
sometimes when I used an entirely grey picture for testing.

Regards,
Klaus