Hello,
On Tue, Nov 24, 2009 at 18:48:40, Nori, Sekhar wrote:
The rtc-omap driver currently hardcodes the RTC to be
not capable of wakeup events. On the DA850/OMAP-L138
SoC, the RTC is a wake up source from its deep sleep
mode.
Let platform data set the wakeup capability flag instead.
Thank you very much Rob,
I'm going to try it now.
Just one open issue is the size of the big buffer:
In the app I cannot be sure what is the buffer size that CMEM allocated
for me, I just know that the size is at least the size that I requested.
Do I have to put the size parameter in these
Albert Burbea wrote:
Hi
thanks for your help - the problem is that the JPEG codec is TI's and I
do not have access to its source code.
What could hang the message queue ?
Thanks again
Albert
Hi everybody,
I am using mv 4.01 with codec engine 2.01. I am integrating the
Hey Rob,
I see that calling the register functions require that CE is in the air
(CERuntimeInit) so it is problematic for us in the same way as doing the
CMEM allocations via CodecEngine.
So I guess I have no solution except redesigning my system such that
CERuntimeInit will be before any buffers
Erez Kinarti wrote:
Hey Rob,
I see that calling the register functions require that CE is in the air
(CERuntimeInit) so it is problematic for us in the same way as doing the
CMEM allocations via CodecEngine.
as you have to call CERuntimeInit() before using any of CE, you can do the
No, because in my system, the first codec that is generated is calling
CERuntimeInit (working with C++, keeping reference counter for the call
to CERuntimeInit and CERuntimeExit), while the system buffers are
allocated before that.
-Original Message-
From:
Erez Kinarti wrote:
No, because in my system, the first codec that is generated is calling
CERuntimeInit (working with C++, keeping reference counter for the call
to CERuntimeInit and CERuntimeExit), while the system buffers are
allocated before that.
well, then move that call outside of the
You are totally correct, it is just that our system is in a validation
stage where we don't want to touch anything (in order to avoid doing all
the testing cycle again), and moving the CERuntimeInit to be before the
buffers allocation will require some changes that I don't want to do in
such
Hi
I want to display an image using DM355 along with a text menu and some other
images on the side. What is the best way that I can manipulate size and
location of images displayed on the screen. Till now I have only managed to
display a full jpeg image using the demo code in DM355 and the frame
Which kernel version number is working for you can I know the kernel
version number and if any patches please let me know the patches also.
- Gopala
From: Gopala Gottumukkala
Sent: Monday, January 04, 2010 9:13 AM
To: 'Subbrathnam, Swaminathan';
Pl. refer to DaVinci Staging GIT kernel hosted at
http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a=summary.
From: Gopala Gottumukkala [mailto:ggott...@cernium.com]
Sent: Tuesday, January 05, 2010 8:06 PM
To: Subbrathnam, Swaminathan;
Thanks for the response!
I'll give the latest CMEM, LinuxUtils, et al a whirl and see what happens. The
strange thing is that the mpeg4 decoder, jpeg encode/decode, and mp3
encode/decode all load without complaint. It's just the mpeg4enc that fails.
I've rebuilt cmemk.ko and dm350mmap.ko
I want to use Full speed instead of high speed. What needs to be done
to work with full speed.
Help appreciated,
Thanks
- Gopala
From: Subbrathnam, Swaminathan [mailto:swami.i...@ti.com]
Sent: Tuesday, January 05, 2010 9:41 AM
To: Gopala Gottumukkala;
First, it looks like your on a DM355 or DM365 as this codec is 'local' (i.e.
running on the same processor as your app). That helps eliminate some
complexity (e.g. no DSP Link, and no DSKT2... the warning msg is misleading -
there's no DSKT2 in a DM355/365 system).
Also from the trace, I can
Hello Gurus,
Looks to me like when I download a new kernel from the git or arago and
do make menuconfig I don't see Davinci related arch. I need to do make
arch-arm davinci_all_defconfig. Then do the make. Is there a way where
you can include the davinci related arch in the system arch.
-
[PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response
registers in davinci_mmc.c
This patch fixes the typos in the comments for the MMC response
registers. They were all /* Response Register 0 and 1 */
Signed-off-by: raghav.m...@gmail.com
---
From
Hello All,
Has anybody have used this NAND Flash with Davinci? The device
(manufacture id is 0x2C device id is 0xAA). I can load both the
ubl_davinci_nand.bin and u-boot-594-nand.bin through CCS(Code Composer
Studio). After I remove the JTAG connector and re-apply the power, the
RBL still seem
On Tue, 2010-01-05 at 12:12 -0800, Naresh Kansara wrote:
Hello All,
Has anybody have used this NAND Flash with Davinci? The device
(manufacture id is 0x2C device id is 0xAA). I can load both the
ubl_davinci_nand.bin and u-boot-594-nand.bin through CCS(Code Composer
Studio). After I remove
raghav n raghav.m...@gmail.com writes:
[PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response registers
in davinci_mmc.c
You don't need to duplicate the subject in the changelog.
This patch fixes the typos in the comments for the MMC response registers.
They were all /*
Kevin Hilman wrote:
raghav n raghav.m...@gmail.com writes:
[PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response registers in
davinci_mmc.c
You don't need to duplicate the subject in the changelog.
This patch fixes the typos in the comments for the MMC response registers. They
Sudhakar Rajashekhara sudhakar@ti.com writes:
This patch set corrects some issues with the existing EDMA
driver and also adds support for EDMA resource (channel/slots)
sharing between two processors (say ARM and DSP).
The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138
EVM
Chris has already responded to your other issues, so please see just one
comment from me below.
Regards,
- Rob
-Original Message-
From: Paul Stuart [mailto:paul_stu...@seektech.com]
Sent: Tuesday, January 05, 2010 7:26 AM
To: Tivy, Robert;
This sounds like an odd setup, how are you even calling the codec if not
through CE?
Since the first codec is assuming responsibility for doing first things, like
calling CERuntime_init(), can't it also call Memory_registerContigBuf()? From
your earlier descriptions it sounds like you might
I would expect that the size that you use is good enough for the
Memory_registerContigBuf() call.
The only way you can query the size of the buffers allocated by CMEM is to do
so in a non-direct manner, by performing %cat /proc/cmem and parsing the
ASCII output (try out that command, you'll
Sekhar Nori nsek...@ti.com writes:
From: Nageswari Srinivasan nagesw...@ti.com
This patch adds the CDCE949 reference oscillator to
the davinci clock list.
On the DM6467T EVM, the CDCE949 is responsible for
generating the pixel clock for display. On the DM6467
EVM, this pixel clock was
On Tue, Jan 5, 2010 at 3:04 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Sekhar Nori nsek...@ti.com writes:
From: Nageswari Srinivasan nagesw...@ti.com
This patch adds the CDCE949 reference oscillator to
the davinci clock list.
On the DM6467T EVM, the CDCE949 is responsible for
Hi,
Thanks for the info. I've updated to the latest cmemk.ko and dm350mmap.ko
modules and still have the issue. Also fails if I pass NULL for the parameter
structure instead of the defaults.
If 0xC080 refers to the M355_MPEG4E_ERROR structure as defined in the MPEG4ENC
user guide (which I'm
Sekhar Nori nsek...@ti.com writes:
This patch adds core power management (suspend-to-RAM)
support for DaVinci SoCs.
The code depends on the the deepsleep feature to suspend
the SoC and saves power by gating the input clock.
The wakeup can be based on an external event as supported
by the
Chaithrika U S chaithr...@ti.com writes:
Some modules do not have PSC to control their clocks.
The 'lpsc' field in the clk structure is 0 for such clocks.
In the clock disable function check for CLK PSC flag before
disabling the PSC. If this is not taken care of then it may
so happen that
m-kariche...@ti.com writes:
From: Muralidharan Karicheri m-kariche...@ti.com
This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v2 of these patches. Two new clocks master and slave
s-paul...@ti.com writes:
From: Sandeep Paulraj s-paul...@ti.com
In DM365 Q0, Q1 and Q2 are used by codecs.
LSP drivers should use Q3.
This patch changes the default queue for DM365.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Thanks. Applying to master, queueing for 2.6.34 in
Chaithrika U S chaithr...@ti.com writes:
Kevin,
With the cpufreq support on DA850/OMAP-L138 SoC we are observing
that audio does not function as expected at all sampling rates
for various operating points. At a CPU frequency of 96MHz, audio
works fine with a sampling frequency of 8kHz. For
s-paul...@ti.com writes:
From: Sandeep Paulraj s-paul...@ti.com
This patch adds support for a SPI master driver for the
DaVinci series of SOCs
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Mark A. Greer mgr...@mvista.com
Signed-off-by: Philby John pj...@in.mvista.com
s-paul...@ti.com writes:
From: Sandeep Paulraj s-paul...@ti.com
This patch adds support for a SPI master driver for the
DaVinci series of SOCs
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Mark A. Greer mgr...@mvista.com
Signed-off-by: Philby John pj...@in.mvista.com
Janakiram Sistla janakiram.sis...@gmail.com writes:
On 12/17/09, Chaithrika U S chaithr...@ti.com wrote:
Improve the suspend and resume callbacks in DaVinci MMC
host controller driver.
[Ram] I came cross in the mailing some days back that direct
.suspend and .resume calls will stop being
Chaithrika U S chaithr...@ti.com writes:
Add a helper function which will aid in changing the reset
status of the controller.
Signed-off-by: Chaithrika U S chaithr...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Applies to Linus' kernel tree.
Sergei Shtylyov sshtyl...@ru.mvista.com writes:
Hello.
Vipin Bhandari wrote:
[Re-replying to all, as I only replied to Vipin the first time.]
This patch adds the support for 8bit MMC cards. The controller
data width is configurable depending on the wires setting in the
platform data
Kevin Hilman khil...@deeprootsystems.com writes:
Dmitry Torokhov dmitry.torok...@gmail.com writes:
On Mon, Dec 07, 2009 at 04:24:59PM -0800, Kevin Hilman wrote:
miguel.agui...@ridgerun.com writes:
From: Miguel Aguilar miguel.agui...@ridgerun.com
Add a function pointer in the platform
Philby John pj...@in.mvista.com writes:
From 062cfba8b86ccd932eaa498980e703295d86a6cb Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Mon, 23 Nov 2009 18:08:33 +0530
Subject: [PATCH] Davinci i2c bus recovery procedure to come out of time out
conditions
Get out of i2c
Grant Likely grant.lik...@secretlab.ca writes:
On Tue, Jan 5, 2010 at 4:46 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
s-paul...@ti.com writes:
From: Sandeep Paulraj s-paul...@ti.com
This patch adds support for a SPI master driver for the
DaVinci series of SOCs
Signed-off-by:
---
drivers/mmc/host/davinci_mmc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index dd45e7c..73a6a14 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -54,9 +54,9
Hi Kevin,
I have tried sending the patch again using git send-email. Hope it should be
in a good shape now. Thank you for the patience and the suggestions.
-raghav
On Wed, Jan 6, 2010 at 3:59 AM, Kevin Hilman khil...@deeprootsystems.comwrote:
Kevin Hilman wrote:
raghav n raghav.m...@gmail.com
High Speed is backward compatible with Full Speed mode. So just connect any
full speed device when acting as host or connect to a full speed port when
acting as device and you should be able to work in full speed.
regards
swami
From:
On Wed, Jan 06, 2010 at 05:23:53, Kevin Hilman wrote:
Janakiram Sistla janakiram.sis...@gmail.com writes:
On 12/17/09, Chaithrika U S chaithr...@ti.com wrote:
Improve the suspend and resume callbacks in DaVinci MMC
host controller driver.
[Ram] I came cross in the mailing some days
On Wed, Jan 06, 2010 at 04:26:44, Kevin Hilman wrote:
Chaithrika U S chaithr...@ti.com writes:
Add suspend and resume callbacks to DaVinci I2C driver.
This has been tested on DA850/OMAP-L138 EVM. The SoC specific
suspend-to-RAM support patch series [1] is needed to test this feature.
This is not an odd setup. The buffers are allocated in other place by
memory manager, and for decoupling the codec should not be aware of
that, it just need to be called with pointers to in/out buffers.
Believe me that we have good enough reason not to do the alloc and
release from the codec. In
46 matches
Mail list logo
