Sergei,
The patches do address the issues for which they were submitted.
1. Busy field update patch ensures that busy field reflects the
current status of the associated EP. In previous implementation busy is
predominantly set to 0 except for a brief time in giveback
From: David Brownell [EMAIL PROTECTED]
Remove remnants of an old OSS-audio-for-DaVinci patch, which
tried to make some OMAP-specific AIC23 code do double duty as
DaVinci AIC33 codec support.
Nowadays there's sane ASoC support for both AIC23 and AIC33
codecs, and there seems to be no need for
From: David Brownell [EMAIL PROTECTED]
Minor bugfix: now that DaVinci kernels can support multiple
boards, board-specific ASoC components need to verify they're
running on the right board before initializing.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
On Monday 08 December 2008, Medisetty, Naresh wrote:
I am working on the dm355 evm audio.
We were waiting for the nfs to work so that we can test the audio thoroughly.
Nice to know that. Maybe the Ethernet patch I posted
earlier will help.
I will get back to you on this as early as
Phil Quiney wrote:
To counter this both JFFS2 YAFFS2 developers have released
updated versions. JFFS2 has become UBIFS (formerly JFFS3) and
YAFFS2 has added checkpointing (to avoid checking all files
by remembering files checked last time). Unfortunately
kernel 2.6.10 is too ancient for
From: David Brownell [EMAIL PROTECTED]
The DaVinci mach/mcbsp.h is full of useless stuff:
(a) It's used with chips that don't *have* a McBSP; instead,
they have an ASP.
(b) Most of the registers and utilities apply to nothing I
can find. Not ASP; not the McBSP on chips like dm642.
Dave,
Yes . The dm6446 EVM support should almost work for the dm355 once resource
naming/addressing issues get sorted out.
McBSP is the device used not only for audio and also for other purposes like
communicating with SPI devices etc, But on dm644x it was used for audio purpose
and hence the
While trying to puzzle out some of those ASoc questions, I noticed
some cleanups that seemed needed. So here are some patches ...
First, the cleanups:
- Remove a remnant of an ancient/obsolete OSS-for-DaVinci patch.
(Part of this -- a header -- made it to mainline.)
- Minor bugfix for a
From: David Brownell [EMAIL PROTECTED]
Generalize the psc_mux() stuff to stop assuming there are only
DM6446 chips, and specifically to handle things the DM355 EVM
will need: SPI0, MMC0, MMC1, ASP1.
Note that I think the clock framework (PSC) and pinmux framework
really ought to be properly
From: David Brownell [EMAIL PROTECTED]
Teach the davinci-evm ASoC support to handle both DM6446
and DM355 EVM boards by recognizing which board they're using,
then setting up appropropriately.
The only particularly ugly bit here is clock handling, where
we need to know the right clock name to
2008/12/3 黄守旺 [EMAIL PROTECTED]
Rajashekhara, Sudhakar,您好！
Can you tell me where can i download a basal rootfs for dm644x?
i want to use jffs2 rootfs
=== 2008-11-27 18:23:03 您在来信中写道：===
Hi,
You can clone the latest tree using git-clone git://
On Mon, Dec 08, 2008 at 10:18:05AM -, Jon Povey wrote:
Phil Quiney wrote:
To counter this both JFFS2 YAFFS2 developers have released
updated versions. JFFS2 has become UBIFS (formerly JFFS3) and
YAFFS2 has added checkpointing (to avoid checking all files
by remembering files
Felipe Balbi wrote:
That's what I did. I run a 32MB root partiton.
I also see these ECC failures for the bad block table. However: the
BBT still gets created, read by u-boot, and flash_erase and yaffs2
mounts seem aware of bad blocks under Linux.. and nothing
has broken
yet..
On Mon, Dec 08, 2008 at 05:28:02PM -, Jon Povey wrote:
Felipe Balbi wrote:
That's what I did. I run a 32MB root partiton.
I also see these ECC failures for the bad block table. However: the
BBT still gets created, read by u-boot, and flash_erase and yaffs2
mounts seem
No, I have not even downloaded the GIT kernel. All my work has been
with the 2.6.10 kernel originally supplied with the EVM. I
follow news
of the GIT kernel on this mailing list and when things look
like they
might work and we would have time, we may try it out.
We would need
Hi,
I am a beginner with the DM355 EVM Board, and I am trying to get the
jpeg codec working in C Code. SPRUE67 says to include 3 header files,
which are
#include xdc/std.h
#include ti/sdo/ce/Engine.h
#include ti/sdo/ce/CERuntime.h
But when I add these headers and nothing else I
On Mon, Dec 08, 2008 at 05:39:18PM -, Jon Povey wrote:
No, I have not even downloaded the GIT kernel. All my work has been
with the 2.6.10 kernel originally supplied with the EVM. I
follow news
of the GIT kernel on this mailing list and when things look
like they
might
Please read through this article - the Codec Engine uses the build types
defined by the XDC tools, and this shows how to integrate this into your build:
http://rtsc.eclipse.org/docs-tip/Consuming_Configurable_Content/makefiles
Fundamentally, you need to add the _generated_ compiler.opt options
Hey,
what could be the reason for the kernel hanging with following message:
Starting Kernel ...
Uncompressing Linux...
and after some changes (i do not remember which) in my development files then i
got this one:
ran out of input data
I'm using git kernel 2.6.26-davinci1 with the patches
On Mon, Dec 08, 2008 at 10:52:31AM -0800, Stankiewicz Bredkjaer wrote:
Hey,
what could be the reason for the kernel hanging with following message:
Starting Kernel ...
Uncompressing Linux...
and after some changes (i do not remember which) in my development files then
i
got this one:
Thanks for the help. I do have further questions, how does one create the
config files, etc. I saw some example in the DM355 directory, but they all use
MPEG Encoding, how does one create a new config file that is specific to JPEG
encoding. Is it as simple as replacing MPEG with JPEG in the
From: Felipe Balbi [EMAIL PROTECTED]
Make dm355's nand flash probe with current driver.
For some reason, the current driver marks way too many
blocks as bad blocks. Later patches will be needed to
fix it.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-davinci/board-dm355-evm.c
From: Felipe Balbi [EMAIL PROTECTED]
Later patch will come to use it in davinci_nand.c and get
rid of a define there. In DM355, the base is different, so
better to apply this patch before adding support for DM355
nand chip.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
From: Felipe Balbi [EMAIL PROTECTED]
Hi all,
I still couldn't flash a jffs2 filesystem to my dm355 so I'm asking anyone
who has a jffs2 flashed to dm355 to test the following patches.
It seems to work fine since I can see the partitions are created, as well
as the devnodes but due to the old
From: Felipe Balbi [EMAIL PROTECTED]
Lot's of cleanups to davinci_nand.c:
- convert printk() to dev_err()
- get control base via struct resource
- add missing static and __init
- remove some useless ifdef
- add some REVISIT notes for later patches
- add locking support for register
On Mon, Dec 08, 2008 at 10:51:46PM +0200, Felipe Balbi wrote:
+ if (IS_ERR(info-clk)) {
+ ret = PTR_ERR(info-clk);
+ dev_dbg(pdev-dev, unable to get AEMIFCLK, err %d, ret);
on little fix here:
- dev_dbg(pdev-dev, unable to get AEMIFCLK, err %d, ret);
On Sun, Dec 07, 2008 at 12:28:38PM -0800, David Brownell wrote:
On Sunday 07 December 2008, Felipe Balbi wrote:
+ platform_set_drvdata(pdev, keys);
+ keys-pdev = pdev;
you could be holding only the device pointer.
keys-dev = pdev-dev;
then, if you really
On Monday 08 December 2008, Felipe Balbi wrote:
Here's an update patch for your input driver:
Looks good, thanks. If someone commits the original
patch, this one has my ack. Else I'll merge this
into the next version I send.
- Dave
___
On Monday 08 December 2008, David Brownell wrote:
Nowadays there's sane ASoC support for both AIC23 and AIC33
codecs, and there seems to be no need for this OSS remnant.
... and the obsolete aic23 OSS-ism just got removed from
the OMAP tree, so there's all the more reason to apply
this patch
Hi,
When I check the UART, it is constantly sending out a BOOTME command. When I
tried sending the sfh command out again it went through but then stopped at
Sending the UBL... Do I have to do something else?
Thanks
Neerav
-Original Message-
From: Griffis, Brad [mailto:[EMAIL
From: David Brownell [EMAIL PROTECTED]
Sure would be nice to have the watchdog device node created, so
the watchdog driver (already in mainline) binds to something.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Hmmm ... doesn't apply against mainline.
arch/arm/mach-davinci/devices.c |
Applying this on top of the preceding sound patches, I get:
Advanced Linux Sound Architecture Driver Version 1.0.18rc3.
ASoC version 0.13.2
AIC3X Audio Codec 0.2
asoc: tlv320aic3x - davinci-i2s mapping ok
ALSA device list:
#0: DaVinci EVM (tlv320aic3x)
Then in
hi all:
The following are on the DM355 DEEP SLEEP code, how power is not, I do
not know how to deal with,
I would like to thank!
/* * linux/arch/arm/mach-davinci/sleep.S * * Assembly sleep routines for
DaVinci * * Copyright 2007 Dirk Behme [EMAIL PROTECTED] * * Based on
33 matches
Mail list logo
