>>
>> Up to now I usually saw the master-slave relationship defined as per
>> whether the protocol is "master" or "slave," which always was used from
>> the PoV of the bridge. I.e., even in a camera datasheet a phrase like
>> "supports master-parallel mode" means supports a mode in which the bridge
Hans,
>
>My last proposal merged subdev and bridge parameters into one struct, thus
>completely describing the bus setup. I realized that there is a problem
>with
>that if you have to define the bus for sub-devices that are in the middle
>of
>a chain: e.g. a sensor sends its video to a image proces
Guennadi,
How is this different from enum_fmt() sub device operation. The pixel format
does specify how bridge device pack the data from sub device into memory
and describe the same to user space applications. Not sure why we need this.
Murali Karicheri
Software Design Engineer
Texas Instrument
>-Original Message-
>From: Santiago Nunez-Corrales [mailto:snu...@ridgerun.com]
>Sent: Wednesday, August 26, 2009 10:48 AM
>To: Linux Media Mailing List; Karicheri, Muralidharan
>Subject: Official/Staging git tree for v4l2?
>
>Good morning,
>
>
>I am currently giving s
ailto:khil...@deeprootsystems.com]
>Sent: Wednesday, August 26, 2009 5:00 AM
>To: Karicheri, Muralidharan; Mauro Carvalho Chehab
>Cc: linux-media@vger.kernel.org; Hans Verkuil; DaVinci
>Subject: davinci vs. v4l2: lots of conflicts in merge for linux-next
>
>OK, this has gotten a bit out of control,
o:mche...@infradead.org]
>Sent: Sunday, August 23, 2009 11:10 PM
>To: Karicheri, Muralidharan
>Cc: Kevin Hilman; Mauro Carvalho Chehab; linux-media@vger.kernel.org; Hans
>Verkuil
>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif
>capture driver
>
>Em T
ent: Wednesday, August 19, 2009 5:04 PM
>To: davinci-linux-open-sou...@linux.davincidsp.com
>Cc: Karicheri, Muralidharan; linux-media@vger.kernel.org
>Subject: Re: [PATCH 3/5 - v3] DaVinci: platform changes to support vpfe
>camera capture
>
>On Monday 17 August 2009, m-kariche...
.com
>-Original Message-
>From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
>Sent: Thursday, August 20, 2009 12:33 AM
>To: Karicheri, Muralidharan; Kevin Hilman
>Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab; linux-
>me...@vger.kernel.org; khil...@deeprootsystems.com; Han
Hans,
You have done a great job in putting up a quick proposal. I was just trying to
understand the intentions/rational behind your proposal to be on the same page.
Thanks for the education. I think this will help others as well.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
auro Carvalho Chehab [mailto:mche...@infradead.org]
>>Sent: Tuesday, August 18, 2009 1:28 PM
>>To: Karicheri, Muralidharan
>>Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux-
>open-
>>sou...@linux.davincidsp.com; khil...@deeprootsystems.com; Hans Verkuil
Russell,
Could you please ack this patch from Chaithrika if you agree with these changes?
I have another set of patches waiting to be submitted and is dependent on this
patch. So you response will be helpful to speed up the process.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instr
Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
>-Original Message-
>From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
>Sent: Tuesday, August 18, 2009 1:28 PM
>To: Karicheri, Muralidhara
ineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
>-Original Message-
>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Tuesday, August 18, 2009 2:51 AM
>To: Karicheri, Murali
t;From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Monday, August 17, 2009 4:27 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.davincidsp.com; khil...@deeprootsystems.com
>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring
icheri, Muralidharan
>Sent: Monday, August 17, 2009 7:19 PM
>To: linux-media@vger.kernel.org
>Cc: davinci-linux-open-sou...@linux.davincidsp.com; hverk...@xs4all.nl;
>Karicheri, Muralidharan
>Subject: [PATCH 1/5 - v3] Adding new fields to add the vpfe capture
>enhancements
>
&g
: 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
>-Original Message-
>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Monday, August 17, 2009 2:47 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.da
erkuil [mailto:hverk...@xs4all.nl]
>Sent: Monday, August 17, 2009 2:47 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.davincidsp.com; khil...@deeprootsystems.com
>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif
remath, Vaibhav
>Sent: Monday, August 17, 2009 12:35 PM
>To: Karicheri, Muralidharan; linux-media@vger.kernel.org
>Cc: davinci-linux-open-sou...@linux.davincidsp.com; hverk...@xs4all.nl
>Subject: RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture
>driver
>
>H Murali,
Vaibhav,
I don't see any serious issues raised here. I can send another patch to fix
this if needed.
Regards,
Murali
>> +#include
>> #include
>> +#include
>[Hiremath, Vaibhav] You may want to put one line gap here.
Ok. Just editorial.
>> +#include
>>
>> #include "vpif.h"
>>
>> @@ -31,6 +3
erkuil [mailto:hverk...@xs4all.nl]
>Sent: Saturday, August 15, 2009 8:10 AM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.davincidsp.com; khil...@deeprootsystems.com
>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif
Hans,
Last week, I had sent vpfe capture (v2) and vpif capture(v1) patches for
review. If they look good, please merge them to your tree and send a pull
request to Mauro at your earliest convenience.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
n
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,
Thanks for reviewing this. I have some questions though against your comments.
Please see below for details..
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
>First of all I've reviewed the other patches in this series and t
Kevin,
Thanks for reviewing this. See below for my response.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
>>
>> #define VIDCH2CLK (BIT(10))
>> #define VIDCH3CLK (BIT(11))
>> +#define VIDCH1CLK (B
Hi Hans,
We need to add support for HD resolutions capture and display in our DM6467
vpif drivers. The vpif display driver is already part of V4L-DVB linux-next
repository and capture driver is being reviewed. The next phase of our
developments involve adding following HD resolutions for capture
dia-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; 박경민; jm105@sam
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
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 Instrume
>-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: davinci-linux-open-sou...@linux.da
Chaithrika,
Could you send the patches inline to Russell King r...@arm.linux.org.uk? This
was what Mauro had suggested to me.
We need to get a resolution on this quickly since I have some patches waiting
to be submitted against display driver and would like to base it on your
patches.
Regard
Hans,
I plan to register for this. Following are some of the issues that I face today
while porting TI DaVinci video drivers to open source:-
1) VPBE display drivers (DM6446,DM355 & DM365): Current implementation of
display drivers uses encoder manager (encoders registers with this framework)
>-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, Nathanie
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: Laure
Laurent,
>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 mult
(&vpif_obj.dev[k]->channel_id));
res = platform_get_resource(pdev, IORESOURCE_IRQ, k-1);
m = res->end;
}
video_dev_alloc_exit:
iounmap(vpif_base);
resource_exit:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region
linux-media-
>ow...@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; �세문;
>대ì�¸ê¸°; 김형ì¤
net.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 number of times using memcpy?
>
>On Wednesday 29 J
>-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; 이세문; 대인기; 김형준
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 defa
>> the details, but I think the strategy were to pass a parameter during
>> kernel boot, for it to reserve some amount of memory that would later be
>> claimed by the V4L device.
>
>It's actually a pretty common strategy for embedded hardware (the "general-
>purpose machine" case doesn't - for n
i.com
>-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
>-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/h
>
>> 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
>d
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.
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.
Ger
Mauro,
Thanks for taking care of this. Did you also apply dm6467 display
patch from Chaithrika?
>> 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 h
Hans,
>> #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
>
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
From: Mauro 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
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 Engi
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
m-kariche...@ti.com
nal 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
nal 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 yo
>Sent: Friday, 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" escreveu:
>
>
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 06, 2009 2: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 foll
9 2: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:
>
Hans,
>
>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 th
...@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
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 hav
>> >
>> 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 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 f
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 majord...@vger
om
>-Original Message-
>From: 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 PATC
>> 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
>> >
>>
>> 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
truments Inc.
>>> Germantown, MD 20874
>>> email: m-kariche...@ti.com
>>>
>>>>-Original Message-
>>>>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>>>>Sent: Monday, June 29, 2009 5:26 AM
>>>>To: Karicheri, Muralidhara
0874
>> email: m-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-op
-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 su
>> >
>> > -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 mo
o: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab
>Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
>
>On Friday 26 June 2009 08:17:05 Hans Verkuil wrote:
>> On Thursday 25 June 2009 20:18:06 Karicheri, Muralidharan wrote:
>> &g
Guennadi,
>
>I thought you would be doing the latter part - v4l2-subdev conversion.
>Which is good. But, you wrote:
>
>> This patch migrates mt9t031 driver from SOC Camera interface to
>> sub device interface. This is sent to get a feedback about the
>> changes done since I am not sure if some of
>
>). 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 on
>-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; davinc
cheri
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; M
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:
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
age-
>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
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 t
age-
>From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
>Sent: Tuesday, June 23, 2009 6:50 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 Mon, 22 Jun 2009 11
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
e
Hi,
>> >
>> > -/**
>> > +/*
>> > * 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 value
>>
>>
>> > +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 =
y Klimov
>Cc: Karicheri, Muralidharan; linux-media@vger.kernel.org; davinci-linux-
>open-sou...@linux.davincidsp.com
>Subject: Re: [PATCH 1/11 - v3] vpfe capture bridge driver for DM355 and
>DM6446
>
>On Wednesday 17 June 2009 23:29:31 Alexey Klimov wrote:
>> Hello,
>>
>>
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.
age-
>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 i
>>
>>
>
>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.
>
>T
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, Muralidha
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
>>
>> [MK]In that case can't the driver just ignore the field polarity? I
>assume that drivers implement the parameter that has support in hardware.
>So it is not an issue.
>
>No, because the same driver runs on hardware that also has the field
>signal. So we need to be able to give information a
Hans,
Thanks for the response.
>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 l
Hans,
Please see my response below.
>> +/* { plus irq }, */
>> /* { I2C_BOARD_INFO("tlv320aic3x", 0x1b), }, */
>
>Huh? What's this? I only know the tlv320aic23b and that's an audio driver.
>
[MK] Thanks to David for answering this.
>> -/* { I2C_BOARD_INFO("tvp5146", 0x5d), }, */
>>
, June 15, 2009 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 Ka
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,
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; dav
=
>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);
>> +
>> + /* 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 b
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
[PA
>> +
>> +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 - h
201 - 300 of 328 matches
Mail list logo
