From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-fx0-f46.google.com ([209.85.161.46]:38895 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750941Ab1BZODa (ORCPT ); Sat, 26 Feb 2011 09:03:30 -0500 Received: by fxm17 with SMTP id 17so2563995fxm.19 for ; Sat, 26 Feb 2011 06:03:28 -0800 (PST) Message-ID: <4D69082E.4010006@gmail.com> Date: Sat, 26 Feb 2011 15:03:26 +0100 From: Sylwester Nawrocki MIME-Version: 1.0 To: Hans Verkuil CC: Sakari Ailus , Guennadi Liakhovetski , Stan , Hans Verkuil , "linux-media@vger.kernel.org" , Laurent Pinchart , saaguirre@ti.com Subject: Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms References: <4D67F3AF.7060808@maxwell.research.nokia.com> <201102261350.12833.hverkuil@xs4all.nl> In-Reply-To: <201102261350.12833.hverkuil@xs4all.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: Sender: 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 >