public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	Sylwester Nawrocki <snjw23@gmail.com>,
	Stan <svarbanov@mm-sol.com>, Hans Verkuil <hansverk@cisco.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	saaguirre@ti.com
Subject: Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
Date: Fri, 25 Feb 2011 20:23:43 +0200	[thread overview]
Message-ID: <4D67F3AF.7060808@maxwell.research.nokia.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1102231020330.8880@axis700.grange>

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.

Regards,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

  parent reply	other threads:[~2011-02-25 18:23 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-22 10:31 [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms Stanimir Varbanov
2011-02-22 10:31 ` [RFC/PATCH 1/1] v4l: Introduce sensor operation for getting interface configuration Stanimir Varbanov
2011-02-22 11:40 ` [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms Guennadi Liakhovetski
2011-02-22 13:32   ` Hans Verkuil
2011-02-22 14:01     ` Aguirre, Sergio
2011-02-22 14:34       ` Guennadi Liakhovetski
2011-02-23 11:15       ` Laurent Pinchart
2011-02-22 14:11     ` Guennadi Liakhovetski
2011-02-22 15:17       ` Hans Verkuil
2011-02-22 15:30         ` Guennadi Liakhovetski
2011-02-22 15:34       ` Stan
2011-02-22 16:27         ` Guennadi Liakhovetski
2011-02-22 17:00           ` Hans Verkuil
2011-02-22 17:08             ` Guennadi Liakhovetski
2011-02-23 11:34               ` Laurent Pinchart
2011-02-22 21:42             ` Sylwester Nawrocki
2011-02-23  8:10               ` Hans Verkuil
2011-02-23  9:31                 ` Guennadi Liakhovetski
2011-02-23 14:06                   ` Aguirre, Sergio
2011-02-23 14:17                     ` Hans Verkuil
2011-02-23 14:46                       ` Guennadi Liakhovetski
2011-02-23 15:30                     ` Laurent Pinchart
2011-02-23 15:52                       ` Guennadi Liakhovetski
2011-02-23 16:02                       ` Hans Verkuil
2011-02-23 16:14                         ` Laurent Pinchart
2011-02-23 16:20                           ` Aguirre, Sergio
2011-02-23 16:46                             ` Guennadi Liakhovetski
2011-02-23 17:45                               ` Aguirre, Sergio
2011-02-24  9:45                                 ` Stanimir Varbanov
2011-02-23 16:28                           ` Hans Verkuil
2011-02-23 16:35                             ` Laurent Pinchart
2011-02-23 16:37                   ` Laurent Pinchart
2011-02-23 16:40                     ` Guennadi Liakhovetski
2011-02-25 18:23                   ` Sakari Ailus [this message]
2011-02-26 12:50                     ` Hans Verkuil
2011-02-26 13:14                       ` Guennadi Liakhovetski
2011-02-26 13:39                         ` Hans Verkuil
2011-02-26 14:03                       ` Sylwester Nawrocki
2011-02-26 14:45                       ` Laurent Pinchart
2011-02-23  9:31                 ` Hans Verkuil
2011-02-23 15:06                   ` Aguirre, Sergio
2011-02-23 11:04   ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D67F3AF.7060808@maxwell.research.nokia.com \
    --to=sakari.ailus@maxwell.research.nokia.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=hansverk@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=saaguirre@ti.com \
    --cc=snjw23@gmail.com \
    --cc=svarbanov@mm-sol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox