On Friday, February 25, 2011 19:23:43 Sakari Ailus wrote: > 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. OK, let me summarize this and if there are no objections then Stan can start implementing this. 1) We need two subdev ops: one reports the bus config capabilities and one that sets it up. Note that these ops should be core ops since this functionality is relevant for both sensors and video receive/transmit devices. 2) The clock sampling edge and polarity should not be negotiated but must be set from board code for both subdevs and host. In the future this might even require a callback with the clock frequency as argument. 3) We probably need a utility function that given the host and subdev capabilities will return the required subdev/host settings. 4) soc-camera should switch to these new ops. Of course, we also need MIPI support in this API. The same considerations apply to MIPI as to the parallel bus: settings that depend on the hardware board design should come from board code, others can be negotiated. Since I know next to nothing about MIPI I will leave that to the experts... One thing I am not sure about is if we want separate ops for parallel bus and MIPI, or if we merge them. I am leaning towards separate ops as I think that might be easier to implement. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
