All,
Did anyone know how to upgrade dm350mmap module (from LSP 1.20 package) to
support the newest kernel 2.6.30? Thanks in advance.
BR,
Jeff
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
Ryan Talbot wrote:
Ah, OK, thanks for the explanation, Rob. I don't know how I missed your
discussion with Kevin when I searched earlier; sorry for the repeat
question.
I guess the current solution is to use user buffers allocated with CMEM,
then, and pass those into the VPFE driver? Is that
m-kariche...@ti.com wrote:
From: Muralidharan Karicheria0868...@gt516km11.gt.design.ti.com
VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446
is this the same set of patches present in the branch staging/vpfe ?
I'm having a doubt with that set of patches. Particularly, I'm having
Hi
I have one problem. I am running image pipe on DM6446 with resolution
2560x1920. All is fine, but I am not able to save data after previewer to
disk. It seems that when I assumed that continuous physical address will be
reflected to continuous virtual, I have been wrong. Is there any way to
HI,
Can anyone tell whether DM365 supports 4:2:0 display. If yes how
is the memory layout
Regards
Shantanu Bhaduri
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
Behalf Of
Hello Every one,
I am newbie on DM6446 EVM.
I am currently working on Codec Engine examples and trying to build it.
I have downloaded DVEVM 1_30_01_41 version from ti website.
I have gone thru the build instructions.html and modified the two files in the
example directory.
xdcpaths..mak and
+/*
+ * 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
Hi all,
I got the following errors whenever I try to write to my flash which is
jffs2 (my root is initramfs):
[ 39.22] physmap-flash.0: Chip not ready for buffer write. Xstatus =
0, status = 0
[ 39.24] Write of 68 bytes at 0x0076000c failed. returned -62,
retlen 0
[ 39.24]
Looks like there's inadvertent spaces at the end of many of the *_INSTALL_DIR
variable assignments in xdcpaths.mak. Trim this trailing white space.
Chris
From: davinci-linux-open-source-boun...@linux.davincidsp.com
Ottavio Campana wrote:
Kevin Hilman wrote:
FYI I've added this series to a staging branch of DaVinci git
after some minor compile updates for the new kernel.
See branch 'staging/vpfe'.
cool. I think I'll try it in a few days.
I tried it today. It seems not to work, let me explain what
It still looks like you're building a DSP-side executable/server. configuring
service.x64P - a *.x64P is a DSP-side server.
Maybe sending the entire build log would help. When you say you only have
server.x64P, do you mean service.x64P?
Is your ARM-side cfg script using
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
This patch adds support for setting bus parameters such as bus type
(Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
etc) in sub device.
Hello all,
My patch 1/10 of this series somehow doesn't make it to
linux-me...@vger.kernel.org. I can see it locally.
Here is the header part of the patch. I can't see any thing wrong.
I have tried re-sending with subject changed as follows, but nothing helped.
Do you know what could cause
On Wednesday 10 June 2009 20:32:25 Guennadi Liakhovetski wrote:
On Tue, 9 Jun 2009, m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
This patch adds support for setting bus parameters such as bus type
(BT.656, BT.1120 etc), width (example 10 bit
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 any question.
I will send an updated patch based on this.
BTW, I
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 a0868...@gt516km11.gt.design.ti.com
Hi,
Now that there is discussion on this let me put how I see it working..
The bridge driver is aware of all the sub devices it is working with. So for
each of the sub device, bridge driver could define per sub device configuration
such as bus type, data width, and polarities as a platform
On Tuesday 09 June 2009 20:46:44 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446
This is the version v2 of the patch series. This is the reworked
version of the driver based on comments
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-me...@vger.kernel.org; davinci-linux-open-
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 accept frames
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 bus
Ryan Talbot wrote:
Ah, OK, thanks for the explanation, Rob. I don't know how I missed
your discussion with Kevin when I searched earlier; sorry for the
repeat question.
I guess the current solution is to use user buffers allocated with
CMEM, then, and pass those into the VPFE
23 matches
Mail list logo
