Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[khalasa@piap.pl (Krzysztof Hałasa)]

Andrey Utkin <andrey.utkin@corp.bluecherry.net> writes:

> In upstream there's no more module parameter for video standard
> (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
> out not to work correctly: the frame is offset, so that in the bottom
> there's black horizontal bar.
> The S_STD ioctl call actually makes difference, because without that
> the frame "slides" vertically all the time. But after the call the
> picture is not correct.

Which kernel version are you using?
I remember there were some problems with earlier versions, where the
NTSC vs PAL wasn't consistenly a bool but rather a raw register value
(or something like this), but it was fixed last time I checked.
I'm personally using SOLO6110-based cards with v3.17 and PAL and it
works, with minimal unrelated patches.

> Any ideas why wouldn't it work to change the mode after the driver load?
> Would it be allowed to add back that kernel module parameter (the one
> passed at module load time)?

I don't think this alone would help.

Looking at my patch queue (will try to remember to have them posted)...
Well, it could be the SDRAM size detection routine. I'm using cards with
64 MB of RAM and the routine repeatedly detected 128 MB or so (max
supported). I have a temporary fix for this but it needs a bit more
work, I have seen a case when it failed (I'm using ARM and MIPS
platforms and they may differ from x86 in endianness, cache coherency
etc).

If you have a card with 64 MB RAM you may want to check if the driver
detects it correctly, and if not e.g. hardcode the size. Otherwise,
I have no idea what could be wrong, it works for me.
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland