> Hi,
>
> Is this ready to get merged or still require discussion before merge?
I want to take a final look at this. I had hoped to do that last weekend,
but I didn't have the time for it then. But I should be able to do it this
weekend.
Regards,
Hans
>
> Murali Karicheri
> Software De
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
On Wed, Jun 17, 2009 at 5:33 PM, Hans Verkuil wrote:
>> I think automatic negotiation is a good thing if it is implemented
>> correctly.
>>
>> Actually, i think modelling software after hardware is a good thing
>> and from that perspective the soc_camera was (and still is) a very
>> good fit for ou
On Wed, 17 Jun 2009, Guennadi Liakhovetski wrote:
> On Wed, 17 Jun 2009, Hans Verkuil wrote:
> > It is my strong opinion that while autonegotiation is easy to use, it is
> > not a wise choice to make. Filling in a single struct with the bus
> > settings to use for each board-subdev combination (usu
> On Wed, 17 Jun 2009, Hans Verkuil wrote:
>
>> It is my strong opinion that while autonegotiation is easy to use, it is
>> not a wise choice to make. Filling in a single struct with the bus
>> settings to use for each board-subdev combination (usually there is only
>> one) is simple, straight-for
On Wed, 17 Jun 2009, Hans Verkuil wrote:
> It is my strong opinion that while autonegotiation is easy to use, it is
> not a wise choice to make. Filling in a single struct with the bus
> settings to use for each board-subdev combination (usually there is only
> one) is simple, straight-forward and
> On Mon, Jun 15, 2009 at 12:33 AM, Guennadi
> Liakhovetski wrote:
>> On Fri, 12 Jun 2009, Hans Verkuil wrote:
>>
>>> On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote:
>>> > On Fri, 12 Jun 2009, Hans Verkuil wrote:
>>> >
>>> > > > 1. it is very unusual that the board designer has to man
On Mon, Jun 15, 2009 at 12:33 AM, Guennadi
Liakhovetski wrote:
> On Fri, 12 Jun 2009, Hans Verkuil wrote:
>
>> On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote:
>> > On Fri, 12 Jun 2009, Hans Verkuil wrote:
>> >
>> > > > 1. it is very unusual that the board designer has to mandate what
Let's begin the maintainers party.
> A board designer knows what the host supports, knows what the sensor
> supports, and knows if he added any inverters on the board, and based on
> all that information he can just setup these parameters for the sensor
> chip. Settings that are fixed on the se
On Sun, 14 Jun 2009, Hans Verkuil wrote:
> The point I'm making here is that since the autoconf part is done in software
> it *can* be changed. And while just looking at the code there is no reason why
> choosing a positive vs. negative polarity makes any difference if both host
> and i2c device s
On Sunday 14 June 2009 17:33:19 Guennadi Liakhovetski wrote:
> On Fri, 12 Jun 2009, Hans Verkuil wrote:
>
> > On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote:
> > > On Fri, 12 Jun 2009, Hans Verkuil wrote:
> > >
> > > > > 1. it is very unusual that the board designer has to mandate wh
On Fri, 12 Jun 2009, Hans Verkuil wrote:
> On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote:
> > On Fri, 12 Jun 2009, Hans Verkuil wrote:
> >
> > > > 1. it is very unusual that the board designer has to mandate what signal
> > > > polarity has to be used - only when there's additional
On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote:
> On Fri, 12 Jun 2009, Hans Verkuil wrote:
>
> > > 1. it is very unusual that the board designer has to mandate what signal
> > > polarity has to be used - only when there's additional logic between the
> > > capture device and the host.
On Fri, 12 Jun 2009, Hans Verkuil wrote:
> > 1. it is very unusual that the board designer has to mandate what signal
> > polarity has to be used - only when there's additional logic between the
> > capture device and the host. So, we shouldn't overload all boards with
> > this information. Board-
> On Wed, 10 Jun 2009, Hans Verkuil wrote:
>
>> On Wednesday 10 June 2009 23:30:55 Guennadi Liakhovetski wrote:
>> > On Wed, 10 Jun 2009, Hans Verkuil wrote:
>> > > My view of this would be that the board specification specifies the
>> > > sensor (and possibly other chips) that are on the board. A
On Wed, 10 Jun 2009, Hans Verkuil wrote:
> On Wednesday 10 June 2009 23:30:55 Guennadi Liakhovetski wrote:
> > On Wed, 10 Jun 2009, Hans Verkuil wrote:
> > > My view of this would be that the board specification specifies the
> > > sensor (and possibly other chips) that are on the board. And to me
>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 Thu, 11 Jun 2009, Karicheri, Muralidharan wrote:
> >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 st
>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
>
>> - 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
>d
t;To: Hans de Goede
>Cc: Jean-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
>> 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
>> p
>
>
> On 06/11/2009 11:33 AM, Hans Verkuil wrote:
>>>
>>> On 06/11/2009 10:35 AM, Hans Verkuil wrote:
>
>
>
>>> Hmm,
>>>
>>> Why would we want the *application* to set things like this *at all* ?
>>> with sensors hsync and vsync and other timing are something between
>>> the bridge and the sensor
On 06/11/2009 11:33 AM, Hans Verkuil wrote:
On 06/11/2009 10:35 AM, Hans Verkuil wrote:
Hmm,
Why would we want the *application* to set things like this *at all* ?
with sensors hsync and vsync and other timing are something between
the bridge and the sensor, actaully in my experience the
>
>
> On 06/11/2009 10:35 AM, Hans Verkuil wrote:
>>> Karicheri, Muralidharan a écrit :
>> We need
>> streaming capability in the driver. This is how our driver works
>> with mt9t031 sensor
>>raw-bus (10 bit)
>> vpfe-capture - mt9t031 driver
>>
On 06/11/2009 10:35 AM, Hans Verkuil wrote:
Karicheri, Muralidharan a écrit :
We need
streaming capability in the driver. This is how our driver works
with mt9t031 sensor
raw-bus (10 bit)
vpfe-capture - mt9t031 driver
|
> Karicheri, Muralidharan a écrit :
>>
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
Karicheri, Muralidharan a écrit :
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
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.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software De
On Wed, 10 Jun 2009, Hans Verkuil wrote:
> On Wednesday 10 June 2009 23:30:55 Guennadi Liakhovetski wrote:
> > On Wed, 10 Jun 2009, Hans Verkuil wrote:
> > > My view of this would be that the board specification specifies the
> > > sensor (and possibly other chips) that are on the board. And to me
On Wednesday 10 June 2009 23:30:55 Guennadi Liakhovetski wrote:
> On Wed, 10 Jun 2009, Hans Verkuil wrote:
> > My view of this would be that the board specification specifies the
> > sensor (and possibly other chips) that are on the board. And to me it
> > makes sense that that also supplies the bu
>> >So, what is missing in the driver apart from the ability to specify
>> >a frame-rate?
>> >
>> [MK] Does the mt9t031 output one frame (snapshot) like in a camera or
>> can it output frame continuously along with PCLK, Hsync and Vsync
>> signals like in a video streaming device. VPFE capture can
On Wed, 10 Jun 2009, Karicheri, Muralidharan wrote:
>
>
> >> We need
> >> streaming capability in the driver. This is how our driver works
> >> with mt9t031 sensor
> >> raw-bus (10 bit)
> >> vpfe-capture - mt9t031 driver
> >> |
On Wed, 10 Jun 2009, Hans Verkuil wrote:
> My view of this would be that the board specification specifies the sensor
> (and possibly other chips) that are on the board. And to me it makes sense
> that that also supplies the bus settings. I agree that it is not complex
> code, but I think it is
>> 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
>>
inux-open-
>sou...@linux.davincidsp.com
>Subject: Re: [PATCH] adding support for setting bus parameters in sub
>device
>
>On Wednesday 10 June 2009 21:59:13 Guennadi Liakhovetski wrote:
>> On Wed, 10 Jun 2009, Hans Verkuil wrote:
>> > On Wednesday 10 June 2009 20:32:25 Guennadi Lia
On Wed, 10 Jun 2009, Karicheri, Muralidharan wrote:
> Guennadi,
>
> Thanks for responding. I acknowledge I need to add
> master & slave information in the structure. Querying
> the capabilities from the sub device is a good feature.
> I will look into your references and let you know if I
> have
On Wednesday 10 June 2009 21:59:13 Guennadi Liakhovetski wrote:
> On Wed, 10 Jun 2009, Hans Verkuil wrote:
> > On Wednesday 10 June 2009 20:32:25 Guennadi Liakhovetski wrote:
> > > On Tue, 9 Jun 2009, m-kariche...@ti.com wrote:
> > > > From: Muralidharan Karicheri
> > > >
> > > > This patch adds s
y, June 10, 2009 2:32 PM
>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..
On Wed, 10 Jun 2009, Hans Verkuil wrote:
> On Wednesday 10 June 2009 20:32:25 Guennadi Liakhovetski wrote:
> > On Tue, 9 Jun 2009, m-kariche...@ti.com wrote:
> > > From: Muralidharan Karicheri
> > >
> > > This patch adds support for setting bus parameters such as bus type
> > > (BT.656, BT.1120 e
On Wednesday 10 June 2009 20:32:25 Guennadi Liakhovetski wrote:
> On Tue, 9 Jun 2009, m-kariche...@ti.com wrote:
> > From: Muralidharan Karicheri
> >
> > This patch adds support for setting bus parameters such as bus type
> > (BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
> > and
On Tue, 9 Jun 2009, m-kariche...@ti.com wrote:
> From: Muralidharan Karicheri
>
> This patch adds support for setting bus parameters such as bus type
> (BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
> and polarities (vsync, hsync, field etc) in sub device. This allows
> bridge
42 matches
Mail list logo
