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

[Hans Verkuil <hverkuil@xs4all.nl>]

Hi Andrey,

On 11/15/2014 02:48 PM, Andrey Utkin wrote:
> Thanks to all for the great help so far, but I've got another issue
> with upstream driver.
> 
> 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.

That's strange. I know I tested it at the time. I assume it is the PAL
standard that isn't working (as opposed to NTSC)? Or does it just always
fail when you switch between the two standards?

> 
> Such change didn't help:
> https://github.com/krieger-od/linux/commit/55b796c010b622430cb85f5b8d7d14fef6f04fb4
> So, temporarily, I've hardcoded this for exact customer who uses PAL:
> https://github.com/krieger-od/linux/commit/2c26302dfa6d7aa74cf17a89793daecbb89ae93a
> rmmod/modprobe cycle works fine and doesn't make any difference from
> reboot, but still it works correctly only with PAL hardcoded for the
> first-time initialization.
> 
> Any ideas why wouldn't it work to change the mode after the driver load?

Not really. I will have to test this next week (either Monday or Friday) with
my solo board.

> Would it be allowed to add back that kernel module parameter (the one
> passed at module load time)?

No. That's a hack, the S_STD call should just work and we need to figure out
why it fails.

Regards,

	Hans