On Sat, 26 Feb 2011, Hans Verkuil wrote: > 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. Sorry, didn't want to comment on this... But to me this sounds like a void argument... Yes, there are _many_ inter-dependencies in the kernel, and if you break code something will stop working... What's new about it??? But no, I do not want to continue this discussion endlessly... > 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. ...remains only to find, who will do this;) So, I'm in minority here, if we don't count all those X systems, successfully using soc-camera with its evil auto-negotiation. If you just decide to do this and push the changes - sure, there's nothing I can do against this. But if you decide to postpone a final decision on this until we meet personally and will not have to circulate the same arguments 100 times - just because the delay is shorter - maybe we can find a solution, that will keep everyone happy. > 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. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
