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
