Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms

[Hans Verkuil <hansverk@cisco.com>]

On Wednesday, February 23, 2011 17:14:41 Laurent Pinchart wrote:
> 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.

You are confusing clock polarity (which is relevant) with data, field, hsync 
and vsync polarities which just invert the meaning of those pins.

I wish I had a whiteboard to draw it, much easier to explain that way.

> 
> 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.

Just for the record: I have no problem with hardcoding these polarities. After 
all, that was my original idea. But they can be negotiated as well.

Regards,

	Hans

> 
> > 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
> 
>