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
> are appear to be contiguous, at least on dm644x
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 vertial direction. Do you have any advice about it?I took a picture in the color bar model.
<>___
Davinci-linux-open-sourc
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
> (says sprs403d table 4-3). You may
Brian,
The intent is to get the SPI driver for DM6446, DM6467 and DM355 into the git
by mid march.
On the Dm355 and DM6467 EVM an instance of SPI is connected to EEPROM. This
makes it possible to test the SPI driver.
On the DM6446 EVM SPI is not "exposed". in other words it is not connected to
Hi all!
I am new in DM355. I want to encode a video stream and send it to network
client PC. what i should do first? where i can find the guide doc i need?
best regards
kaka
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.da
On Thursday 05 February 2009, Kevin Hilman wrote:
> 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.
And on dm6446, it also *works* after compiling and linking ... :)
> Chaithrika, t
On Thursday 05 February 2009, Kevin Hilman wrote:
> The /proc dump only has two types of clocks: PLL or PSC, and the
> ref_clk technically is neither. You'll notice I removed the 'CLK_PLL'
> flag from ref_clk because of the new init and handling of PLL-derived
> clocks.
Ergo my suggestion to labe
David Brownell writes:
> On Thursday 05 February 2009, Kevin Hilman wrote:
>> Notes:
>> - boot-tested on dm6446, dm355, dm6467
>
> Minor glitch on dm355 in procfs: ref_clk isn't hooked up
> to the PSC. Nor to the PLL, for that matter... maybe it
> should just use a null string for non-PSC clock
On Thursday 05 February 2009, Kevin Hilman wrote:
> Notes:
> - boot-tested on dm6446, dm355, dm6467
Minor glitch on dm355 in procfs: ref_clk isn't hooked up
to the PSC. Nor to the PLL, for that matter... maybe it
should just use a null string for non-PSC clocks.
I'd go for merging this. That w
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 4-bit ECC support yet.
Signed-off-by
Mark A. Greer wrote:
Brian,
FYI, there is already an SPI driver that TI is preparing to push out to
the community. I'm not sure who in TI is the acutal engineer doing that
but hopefully, they'll speak up so you can sync up with them.
That would be wonderful. I've been meaning to get this
Brian,
FYI, there is already an SPI driver that TI is preparing to push out to
the community. I'm not sure who in TI is the acutal engineer doing that
but hopefully, they'll speak up so you can sync up with them.
Mark
---
___
Davinci-linux-open-source
Hi all,
we observed a very bad behaviour of gstreamer on davinci dm6443.
We are using latest gstreamer from omapzoom.com and latest ti 2.6.10 kernel
with dvsdk 1.30 (and also 2.00)
If we play a elementary audio stream with gstreamer after every application
exit we lost 48kByte memory.
You can
Overview
- distinguish between PLL1- and PLL2-derived SYSCLKs
- PLL-derived AUX ans bypass clocks are sourced
before the multiplier and divider(s)
- multiple tweaks and updates from David Brownell (thanks!)
Notes:
- boot-tested on dm6446, dm355, dm6467
Signed-off-by: Kevin Hilman
---
arch/arm
"Mark A. Greer" writes:
> On Thu, Feb 05, 2009 at 06:34:06AM -0600, Steve Chen wrote:
>> On Wed, 2009-02-04 at 20:57 -0700, Mark A. Greer wrote:
>> > On Fri, Jan 23, 2009 at 11:45:42PM +0300, Sergei Shtylyov wrote:
>> > > Mark A. Greer wrote:
>> >
>> > >>> With the static data being turning in
"Mark A. Greer" writes:
> On Thu, Feb 05, 2009 at 06:34:06AM -0600, Steve Chen wrote:
>> On Wed, 2009-02-04 at 20:57 -0700, Mark A. Greer wrote:
>> > On Fri, Jan 23, 2009 at 11:45:42PM +0300, Sergei Shtylyov wrote:
>> > > Mark A. Greer wrote:
>> >
>> > >>> With the static data being turning in
On Thu, Feb 05, 2009 at 02:20:22PM +0800, Eric Miao wrote:
> On Thu, Feb 5, 2009 at 2:10 PM, Lennert Buytenhek
> wrote:
> > On Wed, Feb 04, 2009 at 05:02:59PM -0700, Mark A. Greer wrote:
> >
> >> Hi Lennert.
> >
> > Hi Marc,
> >
> >
> >> I'm working on adding support for a DaVinci-like ARM SoC fro
On Thu, Feb 05, 2009 at 06:34:06AM -0600, Steve Chen wrote:
> On Wed, 2009-02-04 at 20:57 -0700, Mark A. Greer wrote:
> > On Fri, Jan 23, 2009 at 11:45:42PM +0300, Sergei Shtylyov wrote:
> > > Mark A. Greer wrote:
> >
> > >>> With the static data being turning into dynamic, what's the win of
>
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
are appear to be contiguous, at least on dm644x. Are these contiguou
David Brownell writes:
> CC drivers/net/davinci_emac.o
> drivers/net/davinci_emac.c:2808:47: error: macro "iounmap" passed 2
> arguments, but takes just 1
> drivers/net/davinci_emac.c: In function 'davinci_emac_probe':
> drivers/net/davinci_emac.c:2808: error: 'iounmap' undeclared (first
On Thursday 05 February 2009, Brian G Rhodes wrote:
> I appreciate the review.
>
> David Brownell wrote:
> > I don't think I see any point to the IRQ support, or
> >
> There is no need presently for the interrupt handler, however I think
> using it for a completion to notify the read/duplex ro
I appreciate the review.
David Brownell wrote:
I don't think I see any point to the IRQ support, or
There is no need presently for the interrupt handler, however I think
using it for a completion to notify the read/duplex routines would
provide better support for SPI data transfer. I am cu
David Brownell writes:
> From: David Brownell
> Subject: davinci_nand: clean up the A1CR hacks
>
> The A1CR hacks aren't really needed on the DM355 EVM; NAND timings
> set by UBL (or whatever) are a bit slower than needed, but that's
> not too bad. Remove, but add a comment in board setup.
>
>
CC drivers/net/davinci_emac.o
drivers/net/davinci_emac.c:2808:47: error: macro "iounmap" passed 2 arguments,
but takes just 1
drivers/net/davinci_emac.c: In function 'davinci_emac_probe':
drivers/net/davinci_emac.c:2808: error: 'iounmap' undeclared (first use in this
function)
drivers/net
Kevin Hilman writes:
> Cc: Chaithrika Subrahmanya
> Signed-off-by: Kevin Hilman
> ---
> Chaithrika, this driver currently requests several memory regions which
> are appear to be contiguous, at least on dm644x. Are these contiguous
> on other devices as well? If so, for your upstream work, yo
Kevin Hilman writes:
> Add arch-specific ioremap() which uses any existing static mappings
> in place of doing a new mapping. From now on, drivers should always
> use ioremap() instead of IO_ADDRESS().
>
> In addition, remove the davinci_[read|write]* macros in favor of using
> ioremap + io[read
David Brownell writes:
> From: David Brownell
>
> Make the DaVinci NAND driver use standard Linux badblock
> table support, by removing a mangled clone of that code.
>
> NAND_USB_FLASH_BBT is a better (faster, clearer) and more
> widely used solution for speedier boot than such needless
> hacks.
Hard-wires the controller base register; use what ioremap()
returns, and offsets from that, so it handles multiple SPI
controllers (as on dm355). Don't use davinci_{readl,writel}
and friends.
Doesn't handle 8-bit words ... i.e. the default. Also,
valid word lengths are from 2..16 bits, not 8..16
Cc: Chaithrika Subrahmanya
Signed-off-by: Kevin Hilman
---
Chaithrika, this driver currently requests several memory regions which
are appear to be contiguous, at least on dm644x. Are these contiguous
on other devices as well? If so, for your upstream work, you might consider
simplifying by jus
Add arch-specific ioremap() which uses any existing static mappings
in place of doing a new mapping. From now on, drivers should always
use ioremap() instead of IO_ADDRESS().
In addition, remove the davinci_[read|write]* macros in favor of using
ioremap + io[read|write]*.
Signed-off-by: Kevin Hi
This series is another effort to get rid of some davinci-specific
hacks for address space mapping in favor of the common ones like
ioremap() + io[read|write]*.
This series converts the core code, some out of tree drivers as well
as a separate patch for the EMAC driver so it can be included in the
Hi, guys,
I'm back from my Chines New Year holiday.
As I've told that I have developed CE2.21 and dsplink1.6 for linux
2.6.18
I've got many msgs that ask to try.
I have to say that my release only support samples within the CE 2.21.
The demos decode/encode/loopback for dvevm is not supported
On Wed, Feb 4, 2009 at 8:05 PM, wrote:
>
> Greetings,
>
> Although there are video commands for u-boot, they require framebuffer
> drivers to be written for them.
> No drivers have been written for DM644x as of yet.
>
> Trust me when I say that going to the U-boot mailing list and asking
> someon
Brian G Rhodes writes:
> drivers/spi/spi_davinci.c | 852
> +
> 1 files changed, 852 insertions(+), 0 deletions(-)
> create mode 100644 drivers/spi/spi_davinci.c
>
scripts/checkpatch.pl reports:
total: 4 errors, 21 warnings, 852 lines checked
Ple
I can think of 2 ways to handle different interrupt handler in
entry-macro.S
1. cp_intc has an ID register. We can read it and handle interrupts
accordingly.
2. Use a variable (similar to how Lennert used phys_offset in the
run-time phys_offset patch) to determine which code to execute. Of
cou
davinci-linux-open-source，您好！
Hi:
i download the kernel 2.6.28-rc6 from montavista git;
when i compile it ,i get the following errors :
In file included from drivers/media/video/davinci_vpfe.c:42:
include/media/davinci_vpfe.h:55:29: media/video-buf.h: No such file or directory
I
36 matches
Mail list logo
