I have a spectrum ' s OMAPL137 evm board.
I want to connect the evm to my 560PCI emulator.
But I can not find proper ccs setup files.
Could anyone give me some advice ?
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm adding mailing list to CC so people can correct me if I'm wrong.
huan...@temobi.com wrote:
> "I want to make tvp5146 capture interface work in 2.6.28-rc6 download from
> montavista git . There were some build errors related it"
>
1. tvp5146 dr
On Fri, 2009-02-06 at 16:01 +0800, yang shaobo wrote:
> I have a spectrum ' s OMAPL137 evm board.
> I want to connect the evm to my 560PCI emulator.
> But I can not find proper ccs setup files.
> Could anyone give me some advice ?
>
You can find CCS setup files and other resources here.
http://s
I have not seen this before. Are you generating the color bar pattern
on the DM355 chip or from the 8200?
- Brad
On Feb 6, 2009, at 12:31 AM, 高松 wrote:
Dear all:
Recently, i found there is some kind of problem in the VGA display
using dm355 and ths8200. The display is sawtooth in the ve
Steve Chen wrote:
> In MVL2.6.10 kernel, there are some drivers modules that does not clean
> up properly during module removal for DaVinci which may cause strange
> problems. I don't know if the MMC driver is among them. May want to
> try just replacing the bad MMC without removing the MMC kerne
On Fri, 2009-02-06 at 09:13 -0500, david.kond...@onqlegrand.com wrote:
> Greetings,
>
> I know everyone is really busy trying to swim upstream, but...
>
> Just thought I'd shoot this out there and see if anyone experienced with
> the MMC/SD driver could provide any info.
>
> We've recently had a
David Brownell writes:
> On Thursday 05 February 2009, David Brownell wrote:
>> > NULL for non-PSC clocks would be ok, but the ARMCLK doesn't have an
>> > LPSC associated with it either, and is not PLL derived.
>>
>> Huh? LPSC #31 on dm355 (says spru3fb table 7-1), and LPSC #0 on dm6467
>> (say
"Subrahmanya, Chaithrika" writes:
> Kevin,
>
>> Below is a version of the patch that actually compiles. :/
>>
>> This should now apply directly to the current davinci git head since
>> I've pushed the base patch.
>>
>> Chaithrika, this driver currently requests several memory regions which
>> a
Greetings,
I know everyone is really busy trying to swim upstream, but...
Just thought I'd shoot this out there and see if anyone experienced with
the MMC/SD driver could provide any info.
We've recently had a few MMC cards go completely belly up within a short
time period.
They all share the
Kevin Hilman writes:
> David Brownell writes:
>
>> On Thursday 05 February 2009, David Brownell wrote:
>>> > NULL for non-PSC clocks would be ok, but the ARMCLK doesn't have an
>>> > LPSC associated with it either, and is not PLL derived.
>>>
>>> Huh? LPSC #31 on dm355 (says spru3fb table 7-1)
Updates from v1:
- add CLK_PSC flag (set at init for clks with 'lpsc' filled out)
- blindly dropped the remaining boot-time PSC inits
Overview
- distinguish between PLL1- and PLL2-derived SYSCLKs
- PLL-derived AUX ans bypass clocks are sourced
before the multiplier and divider(s)
- multiple twea
More followon updates ... clock trees are more complete,
also notice the new PSC_DSP flag (only on dm644x for now).
However, that flag doesn't quite seem sufficient to disable
the DSP and VICP clocks on my ancient dm6446 chip.
- Dave
More small clock tweaks:
- Add PSC_DSP
On Friday 06 February 2009, Kevin Hilman wrote:
> OK, I'll use the dm644x equivalent of the dm355 doc above as the
> standard and leave the ARM at LPSC 31.
At least on those two chips, using it as lpsc 31 ALWAYS_ENABLED
seems to behave OK (e.g. in the patch I just sent along).
- Dave
___
David Brownell writes:
> More followon updates ... clock trees are more complete,
> also notice the new PSC_DSP flag (only on dm644x for now).
>
> However, that flag doesn't quite seem sufficient to disable
> the DSP and VICP clocks on my ancient dm6446 chip.
>
Looks this patch and my v2 do some
Hi all,
I am writing an application that dumps A/V data into the SD Flash card in the
order of around 1.5 MB/sec.
I am trying to use O_DIRECT flag when I open a file into which the A/V data goes. I am
using this flag because I want to shutdown buffer-caching during IO as buffer-cached IO
takes
On Friday 06 February 2009, Kevin Hilman wrote:
> Looks this patch and my v2 do some of the same things, but in slightly
> different ways.
Right, I noticed that too.
> I'll work through merging the two and post a v3.
>
> FYI... in my v2, I dropped the enables of the TPCC and TPTC* domainss
> a
Updates from v1/v2:
- add CLK_PSC flag (set at init for clks with 'lpsc' filled out)
- blindly dropped the remaining boot-time PSC inits
- more lowercase clock names, and removal of '_clk' suffix in strings
and from Dave:
- Add PSC_DSP flag for updating dm644x DSP and VICP clocks
- When disab
David Brownell writes:
> From: David Brownell
>
> More cleanup of the NAND driver; mostly just comments but including
> one small bugfix to the 1-bit ECC computation for nonzero chipselects.
>
> This should get the driver most of the way to seeming reasonable for
> an upstream merge ... but, no
David Brownell writes:
> On Friday 06 February 2009, Kevin Hilman wrote:
>> Looks this patch and my v2 do some of the same things, but in slightly
>> different ways.
>
> Right, I noticed that too.
>
>
>> I'll work through merging the two and post a v3.
>>
>> FYI... in my v2, I dropped the enabl
From: David Brownell
Decouple ASP clk_*() calls from pinmmux for DM355 and DM6446.
This removes the need for dm355_psc_mux(), and is a net minor
source and runtime code shrink.
Note that this keeps the ASoC-related board setup code together,
but unfortunately that still doesn't live in mach-davi
Signed-off-by: Kevin Hilman
---
Probably applies to HEAD, but only tested on top of v3 of clock/pll changes
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/dm355.c| 45 -
arch/arm/mach-davinci/dm644x.c | 56 ++-
arch/arm/mach-da
From: David Brownell
Init the SPI eeprom on the dm355 EVM.
Signed-off-by: David Brownell
---
arch/arm/mach-davinci/board-dm355-evm.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/boar
From: David Brownell
Init the DM355 SPI0 device. Board init code would call this, which
would handle all pinmuxing needed.
This configures the second SPI interrupt for this controller; it's
not clear we'll actually want to use those controller IRQs ... but
the just-posted driver expects to have
This should actually preced the patch I sent a few moments ago,
splitting ASP muxing out from the PSC operations; whoops!
- Generic dm355 init for spi0 device. Is this more or less
how we want to do such device setup?
- DM355 EVM setup for spi0 and the EEPROM.
On Friday 06 February 2009, Kevin Hilman wrote:
> arch/arm/mach-davinci/Makefile | 2 +-
> arch/arm/mach-davinci/dm355.c | 45 -
> arch/arm/mach-davinci/dm644x.c | 56 ++-
> arch/arm/mach-davinci/dm646x.c | 21 -
> arch/arm/mach
Jerry Johns writes:
>
>
>
>
>
> 1) To ensure that the *.mpeg4 file that the DM355 creates is
> good, try playing it back in VLC – yes, VLC can play back these files.
>
> 2) Also, you can use a program called YUVTools to inspect
> the YUV file that you created to ensure it’s in the proper UV
On Wednesday 04 February 2009, David Brownell wrote:
> On Wednesday 04 February 2009, Kumar, Purushotam wrote:
> > I will take the responsibility of taking the MMC driver upstream.
>
> Great, thanks. Appended is a minor it-compiles cleanup patch,
> mostly getting rid of the needless ASM hacks (le
27 matches
Mail list logo