Hi Hans,
On Wed, Oct 3, 2012 at 12:10 PM, Hans Verkuil wrote:
> On Wed October 3 2012 08:27:38 Prabhakar wrote:
>> From: Lad, Prabhakar
>>
>> recent patch with commit id 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86
>> which makes vidioc_s_crop const, was causing a following build warning,
>>
>> vpbe
On Wed October 3 2012 08:27:38 Prabhakar wrote:
> From: Lad, Prabhakar
>
> recent patch with commit id 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86
> which makes vidioc_s_crop const, was causing a following build warning,
>
> vpbe_display.c: In function 'vpbe_display_s_crop':
> vpbe_display.c:640: w
On Mon October 1 2012 14:52:48 Prabhakar wrote:
> From: Lad, Prabhakar
>
> recent patch with commit id 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86
> which makes vidioc_s_crop const, was causing a following build error.
>
> vpfe_capture.c: In function 'vpfe_s_crop':
> vpfe_capture.c:1695: error: ass
From: Lad, Prabhakar
while testing display on dm644x, for ED out-range signals
was observed. This patch fixes appropriate clock setting
for ED.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
Cc: Sekhar Nori
---
arch/arm/mach-davinci/dm644x.c |3 +--
1 files changed, 1 inser
From: Lad, Prabhakar
This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
Cc: Sekhar Nori
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
---
arch/arm/
From: Lad, Prabhakar
recent patch with commit id 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86
which makes vidioc_s_crop const, was causing a following build warning,
vpbe_display.c: In function 'vpbe_display_s_crop':
vpbe_display.c:640: warning: initialization discards qualifiers from pointer
targe
On 31.08.2012 14:50, Hebbar, Gururaja wrote:
> The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
> register offset and missing generic SRAM APIs support
>
> Changes
> - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
> "ti,omap2-mcasp-audio" to identify
On Tue, Oct 02, 2012 at 06:50:14PM +0200, Daniel Mack wrote:
> On 02.10.2012 18:41, Matt Porter wrote:
> > On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
> >> On 02.10.2012 13:06, Sekhar Nori wrote:
> >>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
> On 02.10.2012 11:37, Mark Brown
On 02.10.2012 18:41, Matt Porter wrote:
> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
On 02.10.2012 11:37, Mark Brown wrote:
> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi w
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
> On 02.10.2012 13:06, Sekhar Nori wrote:
> > On 10/2/2012 4:03 PM, Daniel Mack wrote:
> >> On 02.10.2012 11:37, Mark Brown wrote:
> >>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> >>>
> I also agree that ifdef
On Tue, Oct 02, 2012 at 12:33:39PM +0200, Daniel Mack wrote:
> On 02.10.2012 11:37, Mark Brown wrote:
> > On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> >
> >> I also agree that ifdef is not a good solution.
> >> It is better to have this information passed as device_data and vi
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> On 09/22/2012 06:33 PM, Mark Brown wrote:
> > On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
> >
> >> +config SND_DAVINCI_HAVE_SRAM
> >> + bool
> >> + default y if ARCH_DAVINCI=y
> >> + default n if ARCH_OMAP=y
On Tue, Oct 02, 2012 at 04:43:59PM +0530, Sekhar Nori wrote:
> On 10/1/2012 7:20 PM, Ben Gardiner wrote:
> > On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter wrote:
> >> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> >>> Hi Matt,
> >>>
> >>> On 9/29/2012 1:07 AM, Matt Porter wrote:
> >>
On Tue, Oct 02, 2012 at 03:32:55PM +0530, Sekhar Nori wrote:
> On 10/1/2012 6:02 PM, Matt Porter wrote:
> > On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> >> Hi Matt,
> >>
> >> On 9/29/2012 1:07 AM, Matt Porter wrote:
> >>> L3RAM (shared SRAM) is needed for use by several drivers.
>
On Tue, Oct 2, 2012 at 7:13 AM, Sekhar Nori wrote:
> On 10/1/2012 7:20 PM, Ben Gardiner wrote:
>> On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter wrote:
>>> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
Hi Matt,
On 9/29/2012 1:07 AM, Matt Porter wrote:
> L3RAM (share
On 02.10.2012 13:06, Sekhar Nori wrote:
> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>> On 02.10.2012 11:37, Mark Brown wrote:
>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>
I also agree that ifdef is not a good solution.
It is better to have this information passed
On Mon, 2012-10-01 at 12:39 -0400, Matt Porter wrote:
> Anything you can show at this point? ;) I'd be happy to drop the
> half-hack
> for a real API. If not, I'm going to carry that to v2 atm.
This is what I had done sometime back. Feel free to update
diff --git a/include/linux/dmaengine.h
On 10/1/2012 7:20 PM, Ben Gardiner wrote:
> On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter wrote:
>> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>>> Hi Matt,
>>>
>>> On 9/29/2012 1:07 AM, Matt Porter wrote:
L3RAM (shared SRAM) is needed for use by several drivers.
This crea
On 10/2/2012 4:03 PM, Daniel Mack wrote:
> On 02.10.2012 11:37, Mark Brown wrote:
>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>
>>> I also agree that ifdef is not a good solution.
>>> It is better to have this information passed as device_data and via DT it
>>> can
>>> be d
On 02.10.2012 11:37, Mark Brown wrote:
> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>
>> I also agree that ifdef is not a good solution.
>> It is better to have this information passed as device_data and via DT it can
>> be decided based on the compatible property for the devi
On 10/1/2012 6:02 PM, Matt Porter wrote:
> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>> Hi Matt,
>>
>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>>> L3RAM (shared SRAM) is needed for use by several drivers.
>>> This creates a genalloc pool and a hook for the platform code
>>> to p
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> I also agree that ifdef is not a good solution.
> It is better to have this information passed as device_data and via DT it can
> be decided based on the compatible property for the device.
That's not really the problem here - the
On 9/25/2012 4:41 PM, Prabhakar wrote:
> From: Lad, Prabhakar
>
> vpif_display relied on a 1-1 mapping of output and subdev. This is not
> necessarily the case. Separate the two. So there is a list of subdevs
> and a list of outputs. Each output refers to a subdev and has routing
> information. A
Hi Mark,
On 9/22/2012 9:03 PM, Mark Brown wrote:
> On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
>
>> +config SND_DAVINCI_HAVE_SRAM
>> +bool
>> +default y if ARCH_DAVINCI=y
>> +default n if ARCH_OMAP=y
>> +
>
> I've been sitting on this mostly since it seems like
On 09/22/2012 06:33 PM, Mark Brown wrote:
> On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
>
>> +config SND_DAVINCI_HAVE_SRAM
>> +bool
>> +default y if ARCH_DAVINCI=y
>> +default n if ARCH_OMAP=y
>> +
>
> I've been sitting on this mostly since it seems like a step b
25 matches
Mail list logo
