Re: Help needed in understanding v4l2_device_call_all

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bee Hock Goh wrote:
> Mauro,
> 
> Thanks.
> 
> Previously, I have done some limited test and it seem that
> xc2028_signal seem to be getting the correct registered value for the
> detected a signal locked.

With the i2c reads working perfectly, it should be already providing the
signal strength with the current code. Dmitri submitted an interesting
patch that it is probably improving the i2c code. It is a worthy trial.

> Since I am now able to get video working(though somewhat limited since
> it still crashed if i change channel from mythtv), i will be spending
> more time to look getting a lock on the signal.

There are still troubles on video. I tested yesterday, and it still crashing.
Tested on a tm6010 device. Unfortunately, some patch broke support for my
10moons device: it is now failing when reading the firmware. Probably, the
GPIO code is wrong.

> Is line 139,140,155,156 needed? Its slowing down the loading of
> firmware and it working for me with the additional register setting.
> 
>  138 if (addr == dev->tuner_addr << 1) {
> 139 tm6000_set_reg(dev, 0x32, 0,0);
> 140 tm6000_set_reg(dev, 0x33, 0,0);

On my tests with HVR-950H, it makes no difference. Probably, Dmitri approach
should be enough, but it won't solve the slow down, as it adds some delay
on i2c operations.

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux