From: David Brownell dbrown...@users.sourceforge.net
Minor code shrink, avoiding some needless pointer indirections by
passing the mmc_data structure around instead of looking it up.
Also some code path cleanup when starting data transfers.
Signed-off-by: David Brownell
From: David Brownell dbrown...@users.sourceforge.net
Clean up MMC/SD fault handling for transfers with data stages:
- After DMA errors, always issue any STOP needed; aborting DMA
on the host is not sufficient to reset the card's state.
- It does that already after data or command errors;
The following four patches make the MMC/SD driver use EDMA
reload slots to make it get good throughput without needing
to enable CONFIG_MMC_BLOCK_BOUNCE:
- Allocate EDMA slots when NR_SG 1 ... at a typical
one page per scatterlist entry, NR_SG = 16 pages is
64 KB, the same as the biggest
From: David Brownell dbrown...@users.sourceforge.net
Allocate and free (NR_SG - 1) parameter RAM slots, and make max_hw_segs
reflect that. This is a NOP until NR_SG is changed, at which point
those slots *need* to be used.
Unmapping scatterlists must use the original scatterlist length, not
the
From: David Brownell dbrown...@users.sourceforge.net
Kick in scatterlist DMA support for the MMC/SD driver, with NR_SG=16
so this will usually do as much I/O per IRQ as it would using the
block bounce buffer logic. Each DMA segment is most often a single
page; larger segments happen too, over
Hello,
This is an error from the system when a particulat process hogs a lot of memory
and no more memory can be allocated to it.
This can happen either, a lot of memory is leaked in the program or program run
time meory requirement is very high so that the kernel can not allocate memory
any
Vinayagam Mariappan wrote:
Hi,
I am having an AVI file of 10MB and it had more than 150frames.
I have difficulty reading all 150 frames and displaying again.Whenever
i read around 72 frames i am getting the following errors in DM6467.
oom-killer: gfp_mask=0x1d2
DMA per-cpu:
cpu 0 hot:
Jammy,
Try ping your host at that board please. May be the problem is from
phy. while CCS can only test the emac himself.
David Chan (blacksword.david)
On Jan 19, 2009, at 10:34 PM, davinci-linux-open-source-requ...@linux.davincidsp.com
wrote:
tftp problem on dm355
To:
I think this problem is not from nfs. AYK, I've build the fs my self
without any code from mv. But same problem.
But when 2.6.18 used, no such a problem. With 2.6.18, generated by my
own toolchain GCC4.2.4+glibc2.c, no such a request at all. whole
system can be started within 5 seconds (from
Hi ,
We are working on TI's DVEVM6467 processor. When we run any video application
(eg. Capture, Display or Loopback ) continuously for more than 6 to 7 times,
then board gets hanged with the message DaVinci I2C WARNING: i2c: cmd complete
failed: complete = 0x0, icstr = 0x410. After getting
Dhaval,
Try modifying the I2C bus frequency in the drivers/i2c/busses/i2c-davinci.c
file and see what happens.
Regards, Sudhakar
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[davinci-linux-open-source-boun...@linux.davincidsp.com] On
Hello.
Kevin Hilman wrote:
Some of the comments about my earlier EDMA patches touched on issues
in that programming interface, like:
- The single call to allocate DMA resources is overly complex.
- Its programming model doesn't match the hardware well: talking
about master vs. slave,
Hello, I wrote:
Some of the comments about my earlier EDMA patches touched on
issues
in that programming interface, like:
- The single call to allocate DMA resources is overly complex.
- Its programming model doesn't match the hardware well: talking
about master vs. slave, not channels
I am writing a simple application in which i need to generate an event for
every 5 min.
I just created a thread inside the thread i need to create an event for
every 5 min.
I refered to DM6467, there the timers are in kernel and i am not able to
link it in my application.
Suggest me how to
Hi,
I am using TI XDC tools to build a archive instead of executable. I do
not want to link xdc.runtime libraries. But by default it gets linked
into the final archive.
Is there any way to disable this linking of xdc.runtime libraries?
Regards,
Viraj
Hi,
You can use the system call sigalarm(seconds) to do this. Install the sigalarm
handler.
Other option is to use nanosleep system command.
With best regards,
Venkat.
--
From: davinci-linux-open-source-boun...@linux.davincidsp.com
On Tue, 2009-01-20 at 23:33 +0900, kirthika varadarajan wrote:
I am writing a simple application in which i need to generate an event
for every 5 min.
I just created a thread inside the thread i need to create an event
for every 5 min.
I refered to DM6467, there the timers are in kernel
Hello all,
I have started development on an OMAPL137 EWM board with
montavista kernel 2.6.18. But this version has a low mmc/sd speed
driver. This part was improved with the 2.6.24 kernel. I'm looking a
patch for 2.6.24 or higher kernel version.
Thanks
Arnaud
Sergei Shtylyov sshtyl...@ru.mvista.com writes:
Hello, I wrote:
Some of the comments about my earlier EDMA patches touched
on issues
in that programming interface, like:
- The single call to allocate DMA resources is overly complex.
- Its programming model doesn't match the hardware
Kevin Hilman wrote:
Some of the comments about my earlier EDMA patches touched
on issues
in that programming interface, like:
- The single call to allocate DMA resources is overly complex.
- Its programming model doesn't match the hardware well: talking
about master vs. slave, not
Hi Kiruthika,
For high-precision idle'ing refer to the nanosleep() and
clock_nanosleep() functions.
Use CLOCK_MONOTONIC to ensure correct operation around time-leaps
(e.g. as caused by an ntp daemon)
For signals, use the signal interface as already indicated by the other people.
Be aware that
Hello,
kirthika varadaraja wrote:
I just created a thread inside the thread i need to create an event for
every 5 min.
...
I refered to DM6467, there the timers are in kernel and i am not able to
link it in my application.
This is standard C library stuff really, but since I hate when
how to generate events for every 5 min .
Regards
Kiruthika
-- next part --
An HTML attachment was scrubbed...
URL:
http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20090120/05dcf22a/attachment-0001.htm
--
Message: 6
Date
It would be much better to have $SUBJECT change when
the topic changes ...
On Tuesday 20 January 2009, Sergei Shtylyov wrote:
The way I currently see things is a single mach-davinci with support
for dm644x, dm355, dm646x, omapl1x7, etc.
MV too have clinged to the idea of parasitising on
Hello.
David Brownell wrote:
It would be much better to have $SUBJECT change when
the topic changes ...
Sure.
The way I currently see things is a single mach-davinci with support
for dm644x, dm355, dm646x, omapl1x7, etc.
MV too have clinged to the idea of parasitising on the DaVinci
On Tuesday 20 January 2009, Sergei Shtylyov wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to
David Brownell wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x support is to be
David Brownell wrote:
* This allocates a DMA channel and its associated parameter RAM slot.
* The parameter RAM is initialized to hold a dummy transfer.
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -589,7 +589,8 @@ static int __init davinci_acquire_dma_ch
Greetings,
Just a heads up for people still using MV 2.6.10 kernel... it may be old
news but it's worth mentioning.
I don't have 2.6.18 so I can't comment on it's correctness.
Occasionally we see messages regarding problems with I2C on DM644x (and
probably DM6467)... in fact I just replied to
I suspect that until patches appear, discussion can get no
further. Plus, if it's going to be mach-omap-L1 it'd
be good to have enough detail that the OMAP team (and RMK)
can see why it should pair with plat-davinci instead of
the more obvious plat-omap.
Although it has OMAP in the
On Tuesday 20 January 2009, Troy Kisky wrote:
First, great job.
:)
And though I'm fine with the way it is, I thought
you were going to add another function to select the transfer controller
and change other options.
I decided to keep it the way it was ... simpler for me,
plus this way it
Sergei Shtylyov sshtyl...@ru.mvista.com writes:
David Brownell wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved
Hello.
Kevin Hilman wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x
Hello, I wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x support is to
-Original Message-
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Tuesday, January 20, 2009 3:50 PM
To: Griffis, Brad
Cc: Sergei Shtylyov; DaVinci
Subject: Re: omap-L1xxx (WAS: [patch 0/6] EDMA interface updates)
On Tuesday 20 January 2009, Griffis, Brad wrote:
I
Hello.
David Brownell wrote:
The vast majority of the HW IP is shared with the
rest of the DaVinci family. I'm not aware of any HW IP shared with
OMAP (other than MUSB.)
MUSB runs on Blackfin too ... and the MUSB on OMAP-L1xx is
like the DaVinci flavor, given its use of CPPI for DMA.
Hi,
I am trying to make directfb work under my dm355 EVM.
I've managed to cross-compile it correctly along with a test program
supposed to draw a line over a black background.
Drivers are correctly set to davinci/devmem.
I'm working with MV's 2.6.10 kernel.
The program runs without any complain
Hello.
Kevin Hilman wrote:
Some of the comments about my earlier EDMA patches touched on issues
in that programming interface, like:
- The single call to allocate DMA resources is overly complex.
- Its programming model doesn't match the hardware well:
Sergei Shtylyov sshtyl...@ru.mvista.com writes:
Hello.
Kevin Hilman wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common
Sergei Shtylyov sshtyl...@ru.mvista.com writes:
[snip]
There is one thing I found difficult to share between OMAP-L1x and
DaVinci variants. That is the RAM is map to different physical address.
For DaVinci Makefile.boot we have
zreladdr-y := 0x80008000
params_phys-y := 0x8100
On Tuesday 20 January 2009, David Brownell wrote:
Hi David Kevin.
[My apologies for being out of the loop on this. I just subscribed a
few mins ago and still catching up on the emails.]
On Tuesday 20 January 2009, Sergei Shtylyov wrote:
Either way, the lack of a complete proposal (not
On Tuesday 20 January 2009, Kevin Hilman wrote:
If you want to have MUSB support in kernel you can forget your dream
of single kernel image. :-)
That's quite a pursuasive argument.
Yet I haven't seen any proof to it. There's no fundamental
reason it should be so. Details are missing.
On Tuesday 20 January 2009, Mark A. Greer wrote:
- Entirely different dma controller.
Well, different address and fewer hardware events (32 vs 64),
but otherwise they both looked like EDMA. What's different
enough to may you say entirely different?
David, Kevin,
Here is an update on the DM9000 issue.
I spent some time on debugging DM9000 issue - tx timeout and a kernel crash.
In the current version of dm9000 driver (1.3), the hard_start_xmit API for
DM9000 - dm9000_start_xmiit() uses spin_lock_irqsave(db-lock, flags); to
disable the
Mark A. Greer mgr...@mvista.com writes:
On Tuesday 20 January 2009, David Brownell wrote:
Hi David Kevin.
[My apologies for being out of the loop on this. I just subscribed a
few mins ago and still catching up on the emails.]
Hi Mark,
I was hoping you would be joining this thread... :)
Hi all,
I am using DM355 based custom board with MT29F16G08DAA as a NAND chip.
I want to burn UBL and U-Boot in NAND.
I am successfully able to boot the board using SD card.
On U-Boot prompt (got using SD), I am trying to burn UBL and U-Boot
using following commands.
//UBL Descriptor
mw.b
part --
An HTML attachment was scrubbed...
URL:
http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20090120/05dcf22a/attachment-0001.htm
--
Message: 6
Date: Tue, 20 Jan 2009 20:26:55 +0530
From: Viraj Karandikar viraj.karandi
47 matches
Mail list logo
