Googling for sprc343a.gz the first hit leads to the archives of this
list:
Motion Jpeg Demo file can't be unziped.
http://linux.omap.com/pipermail/davinci-linux-open-source/2007-November
/004557.html
http://linux.omap.com/pipermail/davinci-linux-open-source/2007-November/
004558.html
I use linux-2.6.28 kernel for dm6446 board from montavista. It can
work well except that there's some problem in serial console.When
I login linux, I enter a charactor, the charactor will not display
until I enter the next charactor. So there's one charactor delay.
But when I use
Signed-off-by: Purushotam Kumar purusho...@ti.com
---
drivers/mmc/host/davinci_mmc.c | 33 +++--
1 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index b034af6..c631c91 100644
---
Hi Guys,
i had updated to montavista 4.0.1 and tried to run a Video, but this
wasn't very successful. The running video appeared unconfigured.
I' ve used fbset to display the frameBuffer configurations then i got
this:
*r...@150.162.62.61:~# fbset -fb /dev/fb/3
mode 720x480-60
# D:
Liu Hua wrote:
I use linux-2.6.28 kernel for dm6446 board from montavista. It can
work well except that there's some problem in serial console.When
I login linux, I enter a charactor, the charactor will not display
until I enter the next charactor. So there's one charactor delay.
But
I got the same problem and tried to change the input resolution, like
explained in this thread. No results, the same problem. Some different idea?
On Thu, Nov 6, 2008 at 11:18 AM, Maupin, Chase chase.mau...@ti.com wrote:
Craig,
I noticed that the encode data sheet says that the input width
Hi.
I am using the DMEVM board TMS320DM6467 with MontaVista Linux. I ran the
demo with success. The problem began when I tried to modify the demo a
little bit. I want to encode a video in 1080i resolution and the demo only
accept 720p. A tried to do it in different ways and nothing worked until
The MUSB code either expects TXCSR.DMAReqEnab bit cleared in several places
and then proceeds with clearing the TXCSR.DMAMode bit (but does not bother
with actually clearing DMAReqEnab beforehand) or just clears both bits at
once -- while is the programming guide explicitly forbids to clear
Multi-frame isochronous Tx URBs transfers in DMA mode never complete because
musb_host_tx() just doesn't restart DMA on a second frame, only emitting debug
message instead. In order to amend that, we need to factor out programming the
DMA transfer from musb_ep_program() into musb_tx_dma_program()
On Friday 20 February 2009, Purushotam Kumar wrote:
- do {
- status = readl(host-base + DAVINCI_MMCST0);
- if (status == 0)
- break;
- if (handle_core_command(host, status))
- break;
- } while
Can you post the pjt file or its contents? It seems like something is wrong.
Also, can you do Help - About to get the complete version of CCS, BIOS, and
codegen?
From: Jon Arróspide [mailto:j...@gti.ssr.upm.es]
Sent: Thursday, February 19, 2009 3:39 AM
To:
On Fri, Feb 20, 2009 at 11:32:24PM +0300, Sergei Shtylyov wrote:
The MUSB code either expects TXCSR.DMAReqEnab bit cleared in several places
and then proceeds with clearing the TXCSR.DMAMode bit (but does not bother
with actually clearing DMAReqEnab beforehand) or just clears both bits at
once
When you set the breakpoint you'll either get a filled-in red circle, or just
an empty circle. If it's filled-in with red then CCS understands where
you're trying to set the breakpoint. There are file names embedded in the x64P
file along with the symbols, etc.
One thing to be careful about
From: David Brownell dbrown...@users.sourceforge.net
Now that the musb build fixes for DaVinci got merged (RC3?), kick in
the other bits needed to get it finally *working* in mainline:
- Use clk_enable()/clk_disable() ... the always enable USB clocks
code this originally relied on has since
On Fri, Feb 20, 2009 at 01:45:17PM -0800, David Brownell wrote:
@@ -116,7 +116,7 @@
unsigned musb_debug;
module_param(musb_debug, uint, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(debug, Debug message level. Default = 0);
+MODULE_PARM_DESC(musb_debug, Debug message level. Default = 0);
we
On Friday 20 February 2009, Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 01:45:17PM -0800, David Brownell wrote:
@@ -116,7 +116,7 @@
unsigned musb_debug;
module_param(musb_debug, uint, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(debug, Debug message level. Default = 0);
On Fri, Feb 20, 2009 at 02:07:58PM -0800, David Brownell wrote:
On Friday 20 February 2009, Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 01:45:17PM -0800, David Brownell wrote:
@@ -116,7 +116,7 @@
unsigned musb_debug;
module_param(musb_debug, uint, S_IRUGO | S_IWUSR);
On Friday 20 February 2009, Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 02:07:58PM -0800, David Brownell wrote:
On Friday 20 February 2009, Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 01:45:17PM -0800, David Brownell wrote:
@@ -116,7 +116,7 @@
unsigned musb_debug;
On Friday 20 February 2009, Felipe Balbi wrote:
@@ -165,9 +165,19 @@ static void nuke(struct musb_ep *ep, con
if (is_dma_capable() ep-dma) {
struct dma_controller *c = ep-musb-dma_controller;
int value;
+
if (ep-is_in) {
+
Swami,
I'm scanning mail queues for MUSB patches that may need
merging. I think this thread didn't have such a patch,
but it did raise some issues that don't yet seem to have
been resolved.
That said, stall handling has always been a PITA -- only
used by USB mass storage class, and conformance
20 matches
Mail list logo
