On 02/26/2011 01:50 PM, 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. > > 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. Sounds reasonable. In case of MIPI-CSI receiver as a separate subdev I assume it would allow to retrieve settings from sensor subdev and apply them to MIPI-CSI receiver. > > 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. I suppose it wouldn't hurt to have same, parametrized ops for both parallel and serial bus. Just like in the original Stan's RFC. > > Regards, > > Hans > -- 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
