Hi Hans,
On Saturday 26 February 2011 13:50:12 Hans Verkuil wrote:
> On Friday, February 25, 2011 19:23:43 Sakari Ailus wrote:
> > Guennadi Liakhovetski wrote:
> > > On Wed, 23 Feb 2011, Hans Verkuil wrote:
> > >> On Tuesday, February 22, 2011 22:42:58 Sylwester Nawrocki wrote:
> > >>> Clock value
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 Sy
On Saturday, February 26, 2011 14:14:29 Guennadi Liakhovetski wrote:
> On Sat, 26 Feb 2011, 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 Sat, 26 Feb 2011, 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
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 o
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
Hi,
>> Sorry, I accept different opinions, and in the end only one of the two
>> possibilities will be implemented, and either way it'll all work in the
>> end, but, I don't buy either of these arguments.
>
>> Complexity - the code is
>> already there, it is working, it is simple, it has not bro
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_pa
iakhovetski; 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, 2
On Wed, 23 Feb 2011, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Wednesday 23 February 2011 10:31:21 Guennadi Liakhovetski wrote:
>
> [snip]
>
> > Currently soc-camera auto-configures the following parameters:
> >
> > hsync polarity
> > vsync polarity
> > data polarity
>
> Data polarity ? A
Hi Guennadi,
On Wednesday 23 February 2011 10:31:21 Guennadi Liakhovetski wrote:
[snip]
> Currently soc-camera auto-configures the following parameters:
>
> hsync polarity
> vsync polarity
> data polarity
Data polarity ? Are there sensors that can invert the data polarity ?
> master / slave m
On Wednesday 23 February 2011 17:28:39 Hans Verkuil wrote:
> On Wednesday, February 23, 2011 17:14:41 Laurent Pinchart wrote:
> > On Wednesday 23 February 2011 17:02:57 Hans Verkuil wrote:
[snip]
> > > When you switch polarity for data/field/hsync/vsync signals on a simple
> > > bus you just inve
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:
> > > >
> > > >
> > > > > > The on
.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 wr
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:
> > >
> > >
> > > > > The only static data I am concerned about are those that affect
> > > > > signal in
On Wednesday, February 23, 2011 16:30:42 Laurent Pinchart wrote:
> On Wednesday 23 February 2011 15:06:49 Aguirre, Sergio wrote:
> >
> >
> > > > The only static data I am concerned about are those that affect signal
> > > > integrity.
> > >
> > > > After thinking carefully about this I realized
On Wed, 23 Feb 2011, Laurent Pinchart wrote:
> > > Currently soc-camera auto-configures the following parameters:
> > >
> > > hsync polarity
> > > vsync polarity
> > > data polarity
> > > master / slave mode
>
> What do you mean by master/slave mode ?
Many datasheets define a slave mode, in whi
On Wednesday 23 February 2011 15:06:49 Aguirre, Sergio wrote:
>
>
> > > 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 sampl
t: Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
>
> On Wednesday, February 23, 2011 09:10:42 Hans Verkuil wrote:
> > Unfortunately, if a subdev is set to 'sample at rising edge', then that
> does
> > not necessarily mean that the host should sample
On Wed, 23 Feb 2011, Hans Verkuil wrote:
> On Wednesday, February 23, 2011 15:06:49 Aguirre, Sergio wrote:
> > Guennadi and Hans,
> >
> >
> >
> > > > The only static data I am concerned about are those that affect signal
> > > integrity.
> > > > After thinking carefully about this I realized th
On Wednesday, February 23, 2011 15:06:49 Aguirre, Sergio wrote:
> Guennadi and Hans,
>
>
>
> > > 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 rele
Guennadi and Hans,
> > 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 re
On Tuesday 22 February 2011 18:08:40 Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Hans Verkuil wrote:
[snip]
> > I also think that there is a reasonable chance that such bugs can happen.
> > Take a scenario like this: someone writes a new host driver. Initially
> > there is only support fo
Hi Sergio,
On Tuesday 22 February 2011 15:01:57 Aguirre, Sergio wrote:
> On Tuesday, February 22, 2011 7:33 AM Hans Verkuil wrote: > > On Tuesday,
February 22, 2011 12:40:32 Guennadi Liakhovetski wrote:
> > > On Tue, 22 Feb 2011, Stanimir Varbanov wrote:
> > > > This RFC patch adds a new subdev s
Hi Guennadi,
On Tuesday 22 February 2011 12:40:32 Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Stanimir Varbanov wrote:
> > This RFC patch adds a new subdev sensor operation named
> > g_interface_parms. It is planned as a not mandatory operation and it is
> > driver's developer decision to
On Wed, 23 Feb 2011, Hans Verkuil wrote:
> On Tuesday, February 22, 2011 22:42:58 Sylwester Nawrocki wrote:
> > Hi everybody,
> >
> > On 02/22/2011 06:00 PM, Hans Verkuil wrote:
> > > On Tuesday, February 22, 2011 17:27:47 Guennadi Liakhovetski wrote:
> > >> On Tue, 22 Feb 2011, Stan wrote:
> > >
On Wednesday, February 23, 2011 09:10:42 Hans Verkuil wrote:
> Unfortunately, if a subdev is set to 'sample at rising edge', then that does
> not necessarily mean that the host should sample at the same edge. Depending
> on the clock line routing and the integrity of the clock signal the host may
>
On Tuesday, February 22, 2011 22:42:58 Sylwester Nawrocki wrote:
> Hi everybody,
>
> On 02/22/2011 06:00 PM, Hans Verkuil wrote:
> > On Tuesday, February 22, 2011 17:27:47 Guennadi Liakhovetski wrote:
> >> On Tue, 22 Feb 2011, Stan wrote:
> >>
> >>> In principle I agree with this bus negotiation.
Hi everybody,
On 02/22/2011 06:00 PM, Hans Verkuil wrote:
> On Tuesday, February 22, 2011 17:27:47 Guennadi Liakhovetski wrote:
>> On Tue, 22 Feb 2011, Stan wrote:
>>
>>> In principle I agree with this bus negotiation.
>>>
>>> - So. let's start thinking how this could be fit to the subdev sensor
On Tue, 22 Feb 2011, Hans Verkuil wrote:
> On Tuesday, February 22, 2011 17:27:47 Guennadi Liakhovetski wrote:
> > On Tue, 22 Feb 2011, Stan wrote:
> >
> > > In principle I agree with this bus negotiation.
> > >
> > > - So. let's start thinking how this could be fit to the subdev sensor
> > > o
On Tuesday, February 22, 2011 17:27:47 Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Stan wrote:
>
> > In principle I agree with this bus negotiation.
> >
> > - So. let's start thinking how this could be fit to the subdev sensor
> > operations.
>
> Well, I'm afraid not everyone is convinc
On Tue, 22 Feb 2011, Stan wrote:
> In principle I agree with this bus negotiation.
>
> - So. let's start thinking how this could be fit to the subdev sensor
> operations.
Well, I'm afraid not everyone is convinced yet, so, it is a bit early to
start designing interfaces;)
> - howto isolate y
Hi,
Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Hans Verkuil wrote:
>
>> On Tuesday, February 22, 2011 12:40:32 Guennadi Liakhovetski wrote:
>>> On Tue, 22 Feb 2011, Stanimir Varbanov wrote:
>>>
This RFC patch adds a new subdev sensor operation named g_interface_parms.
It is pla
On Tue, 22 Feb 2011, Hans Verkuil wrote:
> Secondly, if we rely on negotiations, then someone at some time might change
> things and suddenly the negotiation gives different results which may not
> work
> on some boards. And such bugs can be extremely hard to track down. So that is
Sorry, the
On Tuesday, February 22, 2011 15:11:49 Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Hans Verkuil wrote:
> > I have no problems with dynamic bus reconfiguration as such. So if the
host
> > driver wants to do lane reconfiguration, then that's fine by me.
> >
> > When it comes to signal i
On Tue, 22 Feb 2011, Aguirre, Sergio wrote:
> For example, at least OMAP3 & 4 has the following pin pairs:
>
> CSI2_DX0, CSI2_DY0
> CSI2_DX1, CSI2_DY1
> CSI2_DX2, CSI2_DY2
> CSI2_DX3, CSI2_DY3
> CSI2_DX4, CSI2_DY4
>
> So, what you do is that, you can control where do you want the clock,
> where
On Tue, 22 Feb 2011, Hans Verkuil wrote:
> On Tuesday, February 22, 2011 12:40:32 Guennadi Liakhovetski wrote:
> > On Tue, 22 Feb 2011, Stanimir Varbanov wrote:
> >
> > > This RFC patch adds a new subdev sensor operation named g_interface_parms.
> > > It is planned as a not mandatory operation an
Hi,
> -Original Message-
> From: Hans Verkuil [mailto:hansv...@cisco.com]
> Sent: Tuesday, February 22, 2011 7:33 AM
> To: Guennadi Liakhovetski
> Cc: Stanimir Varbanov; linux-media@vger.kernel.org;
> laurent.pinch...@ideasonboard.com; Aguirre, Sergio
> Subject: Re
On Tuesday, February 22, 2011 12:40:32 Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Stanimir Varbanov wrote:
>
> > This RFC patch adds a new subdev sensor operation named g_interface_parms.
> > It is planned as a not mandatory operation and it is driver's developer
> > decision to use it or
On Tue, 22 Feb 2011, Stanimir Varbanov wrote:
> This RFC patch adds a new subdev sensor operation named g_interface_parms.
> It is planned as a not mandatory operation and it is driver's developer
> decision to use it or not.
>
> Please share your opinions and ideas.
Yes, I like the idea in prin
This RFC patch adds a new subdev sensor operation named g_interface_parms.
It is planned as a not mandatory operation and it is driver's developer
decision to use it or not.
Please share your opinions and ideas.
---
It tries to create a common API for getting the sensor interface type
- serial or
41 matches
Mail list logo
