Hans,
Thanks for your quick reply on this. I need few clarification though.
My proposal would be something like this:
enum dv_preset {
V4L2_DV_CUSTOM,
V4L2_DV_720P24,
V4L2_DV_720P25,
V4L2_DV_720P30,
V4L2_DV_720P50,
V4L2_DV_720P60,
/* etc */
};
Hans,
I have already changed v4l2_i2c_new_probed_subdev() to
v4l2_i2c_new_subdev_board() in my latest patch set for adding vpif capture
driver for DM6467 that you had reviewed. I think this change is not needed
once that patch is applied.
Murali Karicheri
Software Design Engineer
Texas
Chaithrika,
No need to change this since this is already corrected as part of my vpif
capture patch set that I had submitted for review. I had mentioned this to Hans
as well.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Subrahmanya, Chaithrika
Sent: Monday, July 20, 2009 4:01 AM
To: li...@arm.linux.org.uk
Cc:
Laurent,
Snip
I haven't tried to myself, it's just an idea that I'm throwing in the
discussion.
One of our application engineer had done this and it seems to work fine. But he
mentioned some issues with mmap (didn't remember what issue he had).
The driver is basically written to allocate
20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Thursday, July 30, 2009 10:26 AM
To: Karicheri, Muralidharan
Cc: Laurent Pinchart; Mauro Carvalho
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Thursday, July 30, 2009 10:57 AM
To: Karicheri, Muralidharan
Cc: Laurent Pinchart; Mauro Carvalho Chehab; Dongsoo, Nathaniel Kim;
v4l2_linux; Dongsoo Kim
Hans,
True. However, my experience is that this approach isn't needed in most
cases as long as the v4l driver is compiled into the kernel. In that case
it is called early enough in the boot sequence that there is still enough
unfragmented memory available. This should definitely be the default
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@skynet.be]
Sent: Wednesday, July 29, 2009 3:06 PM
To: Karicheri, Muralidharan
Cc: Mauro Carvalho Chehab; Dongsoo, Nathaniel Kim; v4l2_linux; Dongsoo Kim;
박경민; jm105@samsung.com; 이세문; 대인기; 김형준
Subject: Re: How to save
]
Sent: Wednesday, July 29, 2009 3:06 PM
To: Karicheri, Muralidharan
Cc: Mauro Carvalho Chehab; Dongsoo, Nathaniel Kim; v4l2_linux; Dongsoo Kim;
박경민; jm105@samsung.com; 이세문; 대인기; 김형준
Subject: Re: How to save number of times using memcpy?
On Wednesday 29 July 2009 20:36:25 Karicheri, Muralidharan
...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Wednesday, July 29, 2009 5:52 PM
To: Karicheri, Muralidharan
Cc: Laurent Pinchart; Mauro Carvalho Chehab; Dongsoo, Nathaniel Kim;
v4l2_linux; Dongsoo Kim; 박경민; jm105@samsung.com; �세문;
대�기; 김형준
Subject: Re: How to save number of times
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, July 21, 2009 10:32 AM
To: 'Mauro Carvalho Chehab'
Cc: Subrahmanya, Chaithrika; 'Hans Verkuil'; linux-media@vger.kernel.org
Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro and Hans,
Not sure
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
Sent: Tuesday, July 21, 2009 2:46 AM
To: Karicheri, Muralidharan
Cc: Subrahmanya, Chaithrika; 'Hans Verkuil'; linux-media@vger.kernel.org
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em
Hi,
I am working to add support for DM6467 capture driver. This evm has two tvp5147
chips with different i2c addresses. So will I be able to call
v4l2_i2c_new_subdev_board() twice to have two instances of this driver running?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Mauro,
Thanks. That was what I was thinking, but just want to see what issues I might
face on the way. I am starting the work on DM6467 capture driver and you would
be getting a patch soon for review in the mailing list.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Snip
I don't see any control IDs available for Bayer RGB color space.
In our video hardware, there is a set of Gain values that can be applied
to the Bayer RGB data. We can apply them individually to R, Gr, Gb or B
color components. So I think we need to have 4 more controls defined for
doing
Mauro,
Thanks for taking care of this. Did you also apply dm6467 display
patch from Chaithrika?
Snip
li...@arm.linux.org.uk in cc.
A patch for VPIF updates has also been posted[2] .
Applied on my tree. Not sure if I'll send this week upstream. My middle
finger was damaged due to a very heavy
Hi,
I need to implement some controls for my driver and would like to understand
the control ioctl framework available today. I am not very sure how the control
ioctls are to be implemented and it is not well defined in the specification. I
have provided below my understanding of the below set
Hi,
I need to implement some controls for my driver and would like to understand
the control ioctl framework available today. I am not very sure how the control
ioctls are to be implemented and it is not well defined in the specification. I
have provided below my understanding of the below set
Hans,
snip
#define VIDIOC_S_EXT_CTRLS _IOWR('V', 72, struct v4l2_ext_controls)
#define VIDIOC_TRY_EXT_CTRLS _IOWR('V', 73, struct
v4l2_ext_controls)
Currently they are implemented using proprietary ioctls.
Do you mean proprietary ioctls or proprietary controls? Here you talk about
ioctls
, July 10, 2009 4:25 PM
To: Karicheri, Muralidharan
Cc: Hans Verkuil; linux-media@vger.kernel.org
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Thu, 9 Jul 2009 09:18:47 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:
Mauro,
Could you please let me know
Message-
From: Karicheri, Muralidharan
Sent: Friday, July 10, 2009 4:51 PM
To: 'Mauro Carvalho Chehab'
Cc: Hans Verkuil; linux-media@vger.kernel.org
Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro,
Thanks for your support. I will wait for the comments.
Murali
Message-
From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
Sent: Friday, July 10, 2009 5:08 PM
To: Karicheri, Muralidharan
Cc: Karicheri, Muralidharan; Hans Verkuil; linux-media@vger.kernel.org
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 10 Jul 2009
Hello Russell,
This patch is part of the vpfe capture driver (V4L) that adds platform code for
the driver on DM6446 which is an ARM based SoC. I have attached the original
pull request to this email. Please review this and Let us know your comments.
Thanks.
Murali Karicheri
Hello Russell,
This patch is part of the vpfe capture driver (V4L) that adds platform code for
the driver on DM355 which is an ARM based SoC. I have attached the original
pull request to this email. Please review this and Let us know your comments.
Thanks.
Murali Karicheri
Software Design
Carvalho Chehab [mailto:mche...@infradead.org]
Sent: Friday, July 10, 2009 4:20 PM
To: Hans Verkuil
Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Mon, 6 Jul 2009 20:24:44 +0200
Hans Verkuil hverk...@xs4all.nl
Mauro,
Could you please let me know what your plans are for this pull request?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, July 07
:25 PM
To: linux-media@vger.kernel.org
Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab
Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for
the following:
- tvp514x: Migration to sub-device
To: linux-media@vger.kernel.org
Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab
Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for
the following:
- tvp514x: Migration to sub-device framework
...@ti.com
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
Sent: Thursday, July 02, 2009 7:39 AM
To: Karicheri, Muralidharan
Cc: Hans Verkuil; linux-media@vger.kernel.org
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun
Hans,
snip
I've only one request: can you add something along the lines of:
This is an experimental ioctl that will change in future kernels.
Use with care.
And at the top add: EXPERIMENTAL IOCTL
That way it is unambiguous that this will change. And it definitely has
to change! On the other
to the DaVinci tree and then creating new patches based on
that. That is why my note clearly says Depends on v3 version
of vpfe capture driver patch
Maybe you're not getting my point: that submitting a patch
series against mainline (or almost-mainline) means you don't
trip across goofs like
: Jean-Philippe François [mailto:jp.franc...@cynove.com]
Sent: Monday, June 29, 2009 12:23 PM
To: Karicheri, Muralidharan
Cc: Hans Verkuil; davinci-linux-open-sou...@linux.davincidsp.com; linux-
me...@vger.kernel.org
Subject: Re: [RFC PATCH] adding support for setting bus parameters in sub
device
Hi,
If you insist. Regardless, the $SUBJECT patch had some
significant problems (against current code) and should
not merge.
I had accepted your comment already :(
Murali
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
Mauro,
Thanks for looking into this.
- tvp514x: Migration to sub-device framework
As already pointed, here we have those comments regression. Also, some
functions were changed, but the comments still mentions the older
parameters.
Please fix it on a later patch.
I had sent a patch to fix the
I had sent a patch to fix the comment formatting. If you wish, you could
apply it and wait for another that fix the old parameter descriptions.
Fine. It would be better if Hans could add this on his tree, for me to
import
it together with the other patches.
I have done so.
Hmm...
Mauro,
Thanks for responding...
You should note that I'm not asking you to remove that code, but just to
use
the already existing color balance ioctls, for the existing features, or
otherwise to discuss the need of extra controls.
Ok.
The case of image color controlling, we already have
snip
-static struct tvp514x_platform_data tvp5146_pdata = {
- .clk_polarity = 0,
- .hs_polarity = 1,
- .vs_polarity = 1
Clearly this patch is against neither mainline nor the
current DaVinci GIT tree... I suggest reissuing against
mainline, now that it's got most DM355
-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, June 29, 2009 5:26 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com
Subject: Re: [RFC PATCH] adding support for setting bus parameters
]
Sent: Monday, June 29, 2009 5:26 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com
Subject: Re: [RFC PATCH] adding support for setting bus parameters in sub
device
Hi Murali,
From: Muralidharan Karicheri a0868...@gt516km11
snip
That is because, I have my first (vpfe capture version v3)
patch lined up for merge to upstream/davinci git kernel ...
NOTE: Depends on v3 version of vpfe capture driver patch
What is your suggestion in such cases?
Always submit against mainline. In the handfull of cases
that won't
). I started by converting mx3-camera and mt9t031, and I shall upload an
incomplete patch, converting only these drivers to my testing area,
while I shall start converting the rest of the drivers... So, it is
advisable to wait for that patch to appear and base any future (including
this one) work
Hi, Mauro,
I am using the v4l2_i2c_new_subdev_board() API for the next set of vpfe capture
driver patches. So when do you think this will be merged?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From:
Hi,
Is this ready to get merged or still require discussion before merge?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, June 17, 2009 5:17 PM
To: linux
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Thursday, June 25, 2009 11:18 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab
Subject
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski
Sent: Thursday, June 25, 2009 1:46 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com
-
From: Daniel Glöckner [mailto:daniel...@gmx.net]
Sent: Tuesday, June 23, 2009 3:11 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
Subject: Re: sub devices sharing same i2c address
On Tue, Jun 23, 2009 at 01:10:11PM -0500, Karicheri, Muralidharan wrote:
I am having to switch
Hi,
I am already working on porting MT9T031 driver to sub device framework. I have
communicated this to Guennadi, earlier. So please don't work on it. I am going
to send a patch for review in a week.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Hi,
I am having to switch between two sub devices that shares the same i2c address.
First one is TVP5146 and the other is MT9T031. The second has a i2c switch and
the evm has a data path switch. So in our internal release we could switch
capture inputs between the two by configuring the above
Hans,
Thanks for taking care of this.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Friday, June 19, 2009 8:41 AM
To: Alexey Klimov
Cc: Karicheri
snip
+static int dm355_ccdc_init(void)
+{
+ printk(KERN_NOTICE dm355_ccdc_init\n);
+ if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
+ return -1;
Don't you want to rewrite this to return good error code?
int ret;
printk();
ret =
Hi,
Snip
-/**
+/*
* struct tvp514x_decoder - TVP5146/47 decoder object
- * @v4l2_int_device: Slave handle
- * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @sd: Subdevice Slave handle
* @tvp514x_regs: copy of hw's regs with preset values.
* @pdata:
snip
Can you post your latest proposal for the s_bus op?
I propose a few changes: the name of the struct should be something like
v4l2_bus_settings, the master/slave bit should be renamed to something
like 'host_is_master', and we should have two widths: subdev_width and
host_width.
That way
-
From: Karicheri, Muralidharan
Sent: Wednesday, June 17, 2009 11:44 AM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Muralidharan Karicheri;
Karicheri, Muralidharan
Subject: [RFC PATCH] adding support for setting bus parameters in sub
device
From
Hi Hans Mauro,
The v3 version of the DaVici VPFE Capture driver and TVP514x driver has been
sent to the list for review. I expect this to sail through with out any
comments as I have addressed few minor comments from last review. I think Hans
will send you the pull request for these patches.
Hans,
Thanks for the response.
snip
Polarities have to be set for each side, that's correct. The other
parameters are common for both. Although I can think of scenarios where the
bus width can differ between host and subdev (e.g. subdev sends data on 8
pins and the host captures on 10 with the
Hi Mauro,
[snip]
I'm seeing lots of patches and discussions for OMAP and DaVinci being
handled
at the linux-media Mailing List, as part of the development process of the
open
source drivers.
[MK] I along with Chaithrika are working with Hans Verkuil to get the DaVinci
video drivers added to
Hi,
Any suggestion here?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Karicheri, Muralidharan
Sent
+
+struct v4l2_subdev_bus {
+ enum v4l2_subdev_bus_type type;
+ u8 width;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+
Hans,
Thanks for your review. I will get back to you if I need more
information on your comments.
You have reviewed the following patches in this series...
1,7,8,10
Following are part of this series which requires review as well.
[PATCH 2/10 - v2] ccdc hw device header file for vpfe capture
+ /* set the default image parameters in the device */
+ ret = vpfe_config_image_format(vpfe_dev,
+ vpfe_standards[vpfe_dev-
std_index].std_id);
+ if (ret)
+ goto unlock_out;
Why you check ret value and go to label below?
Probably
=
dm644x_clear_wbl_overflow;
+ else
+ return -ENODEV;
Do you need clean up procedure if you return error here? I mean -
calls to release_mem_region, release_mem_region, etc
Oops! I need to add that. Thanks.
+ spin_lock_init(oper_cfg.vpss_lock);
+
Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, June 15, 2009 1:56 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou
Hans,
I am not clear about some of your comments. Please see below with a [MK] prefix.
+static int debug;
+static u32 numbuffers = 3;
+static u32 bufsize = (720 * 576 * 2);
+
+module_param(numbuffers, uint, S_IRUGO);
+module_param(bufsize, uint, S_IRUGO);
+module_param(debug, int, 0644);
5:46 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com; linux-o...@vger.kernel.org
Subject: Re: Did I miss any other patches or RFCs that need to be reviewed?
On Monday 15 June 2009 20:44:15 Karicheri, Muralidharan wrote:
Hans
Hi,
I would like to explore what level of support is available in the v4l buffer
exchange mechanism for USERPTR buffer exchange.
In our internal release, we had a hack to support this feature. We use
contiguous buffers in our user ptr hack implementation. The buffers are
allocated in a kernel
This is the version v2 of the patch series. This is the reworked
version of the driver based on comments received against the last
version of the patch.
I'll be glad to see this get to mainline ... it's seeming closer
and closer!
What's the merge plan though? I had hopes for
...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Friday, June 12, 2009 12:18 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH (V2)] TVP514x: Migration to sub-device framework - Is
it approved ???
On Friday 12 June 2009 18:04
Why force all platforms to set it if the driver is perfectly capable do
this itself? As I said - this is not a platform-specific feature, it's
chip-specific. What good would it make to have all platforms using
mt9t031 to specify, that yes, the chip can use both falling and rising
pclk edge,
-Philippe François; Karicheri, Muralidharan; davinci-linux-open-
sou...@linux.davincidsp.com; Muralidharan Karicheri; Guennadi Liakhovetski;
linux-media@vger.kernel.org
Subject: Re: mt9t031 (was RE: [PATCH] adding support for setting bus
parameters in sub device)
On 06/11/2009 11:33 AM, Hans Verkuil
- video streaming devices like the davinci videoports where you can hook
up HDTV receivers or FPGAs: here you definitely need a new API to setup
the streaming parameters, and you want to be able to do that from the
application as well. Actually, sensors are also hooked up to these
devices
On Wed, 10 Jun 2009, Karicheri, Muralidharan wrote:
So how do I know what frame-rate I get? Sensor output frame rate depends
on the resolution of the frame, blanking, exposure time etc.
This is not supported.
I am still not clear. You had said in an earlier email that it can support
I am sorry, I do not know how I can explain myself clearer.
Thanks for helping me to understand better :)
Yes, you can stream video with mt9t031.
No, you neither get the framerate measured by the driver nor can you set a
specific framerate. Frames are produced as fast as it goes, depending on
+/*
+ * Some sub-devices are connected to the bridge device through a bus
that + * carries * the clock, vsync, hsync and data. Some interfaces
such as BT.656 + * carries the sync embedded in the data where as
others have separate line + * carrying the sync signals. The structure
20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, June 09, 2009 2:47 PM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Muralidharan Karicheri;
Karicheri, Muralidharan
Subject: [PATCH 0/10
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com; Muralidharan Karicheri
Subject: Re: [PATCH] adding support for setting bus parameters in sub
device
On Tue, 9 Jun 2009, m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868
We need
streaming capability in the driver. This is how our driver works
with mt9t031 sensor
raw-bus (10 bit)
vpfe-capture - mt9t031 driver
||
V V
VPFE
Hans,
Great! I look forward for your comments.
Murali Karicheri
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Wednesday, June 10, 2009 5:28 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou
Hans,
Thanks for looking into this...
1) I want to use v4l2_i2c_new_probed_subdev_addr() to load and probe the
the v4l2 sub-device from my vpfe capture driver. Currently the api's
available doesn't allow setting platform data in the client before the
sub-device's probe is called. I see
Please ignore this, it has wrong series number. I will re-send it soon
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, June 09, 2009 2:50 PM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Muralidharan
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, June 09, 2009 5:03 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com; Muralidharan Karicheri
Subject: Re: [PATCH RFC
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@skynet.be]
Sent: Friday, June 05, 2009 12:44 PM
To: Karicheri, Muralidharan
Cc: linux
Laurent,
Laurent,
Thanks for reviewing this. See my response below for few comments. Rest of them
I have incorporated into my next patch.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
+
+/* register
My first reaction to this is... no. I'm reluctant to have a bunch of
driver specific hooks in the core davinci SoC specific code. I'd much
rather see this stuff kept along with the driver in drivers/media/*
and abstracted as necessary there.
I agree with Kevin on this. arch/* is mostly
Laurent,
See my responses below. I have accepted and modified the code based on your
comments. Few are discussed here for conclusion.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
+#include media/tvp514x.h
Hi,
1) I want to use v4l2_i2c_new_probed_subdev_addr() to load and probe the
the v4l2 sub-device from my vpfe capture driver. Currently the api's available
doesn't allow setting platform data in the client before the sub-device's probe
is called. I see that there is discussion about adding
Laurent,
Thanks for reviewing this. I have not gone through all of your comments, but
would like to respond to the following one first. I will respond to the rest as
I do the rework.
I've had a quick look at the DM355 and DM6446 datasheets. The CCDC and VPSS
registers share the same memory
Sergio,
Is it part of the patches Vaibhav others from TI are submitting to open
source ? I know that there is an ongoing effort at TI India to submit the
resizer driver to open source for OMAP3? As per the email exchanges I had with
Vaibhav (TI India) on this, it is part of the ISP module. We
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
Subject: Re: MT9T031 and other similar sub devices...
Hi Murali
On Tue, 19 May 2009, Karicheri, Muralidharan wrote:
Hi, Guennadi Liakhovetski,
Thanks for your effort to migrate the sensor drivers to sub device
framework.
We have
Hi, Guennadi Liakhovetski,
Thanks for your effort to migrate the sensor drivers to sub device framework.
We have interest in mt9t031 and other sensor drivers from Micron since this
peripheral is used in our DM355/DM6446 EVMs as well. I have submitted a set of
patches for our vpfe_capture
201 - 290 of 290 matches
Mail list logo
