Hi, > -----Original Message----- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Wednesday, February 23, 2011 10:15 AM > To: Hans Verkuil > Cc: Aguirre, Sergio; Guennadi Liakhovetski; Hans Verkuil; Sylwester > Nawrocki; Stan; linux-media@vger.kernel.org > Subject: Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms > > On Wednesday 23 February 2011 17:02:57 Hans Verkuil wrote: > > On Wednesday, February 23, 2011 16:30:42 Laurent Pinchart wrote: > > > On Wednesday 23 February 2011 15:06:49 Aguirre, Sergio wrote: > > > > <snip> > > > > > > > > > > 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. > > > > > > > > I respectfully disagree. > > > > > > So do I. Sampling edge is related to polarities, so you need to take > both > > > into account. > > > > When you switch polarity for data/field/hsync/vsync signals on a simple > bus > > you just invert whether a 1 bit is output as high or low voltage. So you > > just change the meaning of the bit. This does not matter for signal > > integrity, since you obviously have to be able to sample both low and > high > > voltages. It is *when* you sample that can have a major effect. > > When you switch the polarity you will likely have to sample on the > opposite > edge. If, for signal integrity reasons, you can only sample on a given > edge, > you will want to use a fixed polarity and not negotiate it.
I guess this should be reason enough to decide this in platform data in the board file. > > Given the very small number of parameters that are negotiated by soc- > camera at > the moment, I'm very much in favour of hardcoding all of them in platform > data > and just adding a g_interface_parms subdev operation. I'll second that. Negotiating all this adds unnecessary complexity, and just makes the code More prone to errors, and even probably causing hardware damage due to misconfiguration. It's better to keep this static and make the board config fully conscious of it. Regards, Sergio > > > This might be different for differential clocks. I have no experience > with > > this, so I can't say anything sensible about that. > > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
