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
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Tue Feb 22 19:00:36 CET 2011
git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f
git media-master: gcc version: i6
On Tue, 22 Feb 2011, Hans Verkuil wrote:
> On Tuesday, February 22, 2011 17:39:25 Guennadi Liakhovetski wrote:
> > On Tue, 22 Feb 2011, Hans Verkuil wrote:
> >
> > > > Hi
> > > >
> > > > Any thoughts about the subj? Hasn't anyone run into a need to select
> > > > inputs on subdevices until now? S
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:39:25 Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Hans Verkuil wrote:
>
> > > Hi
> > >
> > > Any thoughts about the subj? Hasn't anyone run into a need to select
> > > inputs on subdevices until now? Something like
> > >
> > > struct v4l2_subdev_video_ops {
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
Hi Mauro,
Please pull from my gspca tree, for a new driver for the vicam, removal of the
old vicam driver from staging, some gspca_sn9c20x fixes and a gspca_cpia1 fix.
Note this pull request supersedes my previous one.
The following changes since commit 5ed4bbdae09d207d141759e013a0f3c24ae76ecc:
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
On Mon, Feb 21, 2011 at 7:27 PM, Oleg Nesterov wrote:
> On 02/21, Oleg Nesterov wrote:
>>
>> On 02/21, Peter Zijlstra wrote:
>> >
>> > afaict its needed because struct signal_struct and struct sighand_struct
>> > include a wait_queue_head_t. The inclusion seems to come through
>> > completion.h, b
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
Hi
Any thoughts about the subj? Hasn't anyone run into a need to select
inputs on subdevices until now? Something like
struct v4l2_subdev_video_ops {
...
int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input *inp);
int (*g_input)(struct v4l2_subdev *sd, unsigned int
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: [RFC/PATCH 0/1] New sub
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
Hans, can you weigh in on this? I'm waiting to submit a patch to
implement lane shifter support until I get a consensus what the best
approach is. Laurent and Sakari favor having a different format on the
sensor output than on the CCDC input to indicate a shift.
If you agree that this is a sensi
On Tue, Feb 15, 2011 at 4:23 PM, Dennis Kurten wrote:
> Hello Andy, I've tried some of your suggestions, but no luck so far.
>
>
> On Tue, Feb 15, 2011 at 4:09 AM, Andy Walls wrote:
>> On Mon, 2011-02-14 at 13:35 +0200, Dennis Kurten wrote:
>>> Hello,
>>>
>>> This card (technisat cablestar hd 2 d
On Tuesday, February 22, 2011 13:12:32 Mauro Carvalho Chehab wrote:
> Em 22-02-2011 04:53, Hans Verkuil escreveu:
> > Actually, v4l2-ctrl and qv4l2 handle 'holes' correctly. I think this is a
> > different bug relating to the handling of V4L2_CTRL_FLAG_NEXT_CTRL. Can
you
> > try this patch:
> >
>
Em 22-02-2011 04:53, Hans Verkuil escreveu:
> Actually, v4l2-ctrl and qv4l2 handle 'holes' correctly. I think this is a
> different bug relating to the handling of V4L2_CTRL_FLAG_NEXT_CTRL. Can you
> try this patch:
>
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ct
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
Em 22-02-2011 04:53, Hans Verkuil escreveu:
> On Tuesday, February 22, 2011 03:52:11 Mauro Carvalho Chehab wrote:
>> Em 21-02-2011 23:17, Mauro Carvalho Chehab escreveu:
>>> This series contain a minor cleanup for tuner and tvp5150, and two fixes
>>> for em28xx controls. Before the em28xx patches,
I've finally managed to make some measurements on the adapter card
regarding power. At the soldering where the wires from the molex are
connected there is indeed both 5 & 12V. I haven't successfully measured
the PCI pins directly though, but they should be up the specs if there
isn't some internal
Hi,
On 02/22/2011 10:03 AM, Mike Booth wrote:
KVDR has a number of different parameters including
-xforce xv-mode on startup and disable overlay-mod
-ddont switch modeline during xv
with kernel 2.6.35 I run KVDR with -x as I have an NVIDIA grap
Introduce g_interface_parms sensor operation for getting sensor
interface parameters. These parameters are needed from the host side
to determine it's own configuration.
Signed-off-by: Stanimir Varbanov
---
include/media/v4l2-subdev.h | 42 ++
1 files ch
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
Use soc_camera_platform helper functions to dynamically manage the
camera device.
Signed-off-by: Guennadi Liakhovetski
---
arch/arm/mach-shmobile/board-mackerel.c | 28 +++-
1 files changed, 7 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-mac
Use soc_camera_platform helper functions to dynamically manage the
camera device.
Signed-off-by: Guennadi Liakhovetski
---
arch/sh/boards/mach-ap325rxa/setup.c | 32 +---
1 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/arch/sh/boards/mach-ap325rxa/s
Add helper inline functions to correctly manage dynamic allocation and
freeing of platform devices. This avoids the ugly code to nullify
device objects.
Signed-off-by: Guennadi Liakhovetski
---
include/media/soc_camera_platform.h | 49 +++
1 files changed, 49 in
This patch series switches soc_camera_platform users to manage their
camera device instances dynamically instead of re-using static objects.
Since I don't have any of affected platforms at hand, this is only
compile-tested. Please, test!
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelanc
KVDR has a number of different parameters including
-xforce xv-mode on startup and disable overlay-mod
-ddont switch modeline during xv
with kernel 2.6.35 I run KVDR with -x as I have an NVIDIA graphics. Running
on 2.6.38 KVDR -x doesn't produce a
32 matches
Mail list logo