Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms

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

 



Hi Guennadi and others,

Apologies for the late reply...

Guennadi Liakhovetski wrote:
> On Wed, 23 Feb 2011, Hans Verkuil wrote:
> 
>> On Tuesday, February 22, 2011 22:42:58 Sylwester Nawrocki wrote:
>>> Clock values are often being rounded at runtime and do not always reflect exactly
>>> the numbers fixed at compile time. And negotiation could help to obtain exact
>>> values at both sensor and host side.
>>
>> The only static data I am concerned about are those that affect signal integrity.
>> After thinking carefully about this I realized that there is really only one
>> setting that is relevant to that: the sampling edge. The polarities do not
>> matter in this.
> 
> Ok, this is much better! I'm still not perfectly happy having to punish 
> all just for the sake of a couple of broken boards, but I can certainly 
> much better live with this, than with having to hard-code each and every 
> bit. Thanks, Hans!

How much punishing would actually take place without autonegotiation?
How many boards do we have in total? I counted around 26 of
soc_camera_link declarations under arch/. Are there more?

An example of hardware which does care about clock polarity is the
N8[01]0. The parallel clock polarity is inverted since this actually
does improve reliability. In an ideal hardware this likely wouldn't
happen but sometimes the hardware is not exactly ideal. Both the sensor
and the camera block support non-inverted and inverted clock signal.

So at the very least it should be possible to provide this information
in the board code even if both ends share multiple common values for
parameters.

There have been many comments on the dangers of the autonegotiation and
I share those concerns. One of my main concerns is that it creates an
unnecessary dependency from all the boards to the negotiation code, the
behaviour of which may not change.

Regards,

-- 
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx
--
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