OMAPL137 evm and XDS560

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

Re: i need your help for VPFE driver

-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

Re: OMAPL137 evm and XDS560

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

Re: the sawtooth appearance of VGA (using dm355 and ths8200)

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

Re: MV 2.6.10 mmc corruption?

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

Re: MV 2.6.10 mmc corruption?

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

Re: [PATCH] clock: more clock and PLL framework updates

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

Re: [PATCH v3 2/2] NET: davinci emac: convert to using ioremap()

"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

MV 2.6.10 mmc corruption?

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

Re: [PATCH] clock: more clock and PLL framework updates

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)

[PATCH v2] clock: more clock and PLL framework updates

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

Re: [PATCH] clock: more clock and PLL framework updates

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

Re: [PATCH] clock: more clock and PLL framework updates

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 ___

Re: [PATCH] clock: more clock and PLL framework updates

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

Writing streaming content on to SD Flash

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

Re: [PATCH] clock: more clock and PLL framework updates

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

[PATCH v3] clock: more clock and PLL framework updates

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

Re: [patch davinci-git] davinci_nand: cleanup

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

Re: [PATCH] clock: more clock and PLL framework updates

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

[patch davinci-git] more clock/mux splitting: ASP/ASoC

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

[PATCH] davinci: mux: move pin setup into device-specific init

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

[patch davinci-git 2/2] dm355 evm SPI EEPROM setup

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

[patch davinci-git 1/2] dm355 generic spi0 setup

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

[patch davinci-git 0/2] dm355 spi0 setup

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.

Re: [PATCH] davinci: mux: move pin setup into device-specific init

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

Re: 320x240 LCD and MPEG Decode/Stills

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

Re: FYI: upstream-cleanup branch

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