All,
When I checked the LSP 1.20 release notes, i saw a known issues as below
"DM355/DM6446: Mpeg4 + Speech Decode stress gets stuck after 13 hours.
Running the Decode demo (Mpeg4 + Speech) hangs, after running it for 13
hours. The EDMA channel requested by the Audio driver stops generating
inter
> -Original Message-
> From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
> Sent: Thursday, May 07, 2009 6:37 PM
> To: David Brownell
> Cc: Narnakaje, Snehaprabha; dw...@infradead.org; davinci-linux-open-
> sou...@linux.davincidsp.com; linux-...@lists.infradead.org;
> t...@linutroni
Hi Andrea,
> We referred to "dvtb test benchmark" inside the DVSDK, in order to check
> our hardware configurations, and performance of our applications.
Can you tell me what settings you use in dvtb? I've run it through with
the following settings, and it still only gives me 11ms/frame. This is
+static struct nand_ecclayout hwecc4_2048 __initconst = {
+ .eccbytes = 10,
>>> Not ".eccbytes = 40"? This is 4 chunks, 10 ecc bytes each...
>> No, .eccbytes is for each chips->ecc.steps.
>
> So it's the same as ecc.bytes, which is not exported to userspace.
>
>
>> And all nand
Hi all,
I am using Montavista Linux (2.6.10) tha came on the Evaluation board, with
the lastest updates from "DM355 DVEVM Software Updates".
I am having the same problems as Tom reported, randomly the codec gets
isolated and I lost connectivity with the board. Curious thing is that the
board stil
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Thursday, May 07, 2009 1:11 PM
> To: Narnakaje, Snehaprabha
> Cc: davinci-linux-open-source@linux.davincidsp.com; linux-
> m...@lists.infradead.org; dw...@infradead.org; t...@linutronix.de;
> a...@linux-found
Kevin,
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
> Of Kevin Hilman
> Sent: Thursday, May 07, 2009 1:08 PM
> To: David Brownell
> Cc: davinci-linux-open-source@linux.davinci
On Thursday 07 May 2009, Narnakaje, Snehaprabha wrote:
> > I'm glad to see this patch is so small ... basically, just
> > adding a special case for 2K pages, and keeping the core of
> > this NAND driver the same. Not needing to change the 4-bit
> > ECC support from the patch I sent earlier seems
David Brownell writes:
> On Thursday 30 April 2009, Kevin Hilman wrote:
[...]
>
>> At the same time, unless I hear some screaming, I plan to drop all the
>> other davinci_*_defconfig files as I never test them (or plan to) but
>> do get various reports about them.
>>
>> I'll happlily add an alt
On Thursday 07 May 2009, vimal singh wrote:
> >> How about leaving bytes '4' and '5' for bad block marker, to support 16-bit
> >> NAND parts too.
> >
> > This 4-bit ECC engine only works for 8-bit wide parts ...
> > or are you suggesting that in case TI re-engineers that
> > engine in the future?
>
David Brownell writes:
> From: David Brownell
>
> Fix two IRQ triggering bugs affecting GPIO IRQs:
>
> - Make sure enabling with IRQ_TYPE_NONE ("default, unspecified")
>isn't a NOP ... default to both edges, at least one must work.
>
> - As noted by Kevin Hilman, setting the irq trigger t
David Brownell writes:
> From: David Brownell
>
> Remove dm6446-specific SRAM allocator, as preparation for a
> more generic replacement.
>
> Signed-off-by: David Brownell
Thanks, pushing this series of 3 patches today.
Kevin
> ---
> Nothing in-kernel uses this...
>
> arch/arm/mach-davinci/
Laurent,
I need to re-visit following comments as I found something different
after going through the videobuf-core.c
>[snip]
>
>> > > +static void vpfe_videobuf_queue(struct videobuf_queue *vq,
>> > > +struct videobuf_buffer *vb)
>> > > +{
>> > > +/* Get the file
Dave,
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Thursday, May 07, 2009 3:17 AM
> To: Narnakaje, Snehaprabha
> Cc: davinci-linux-open-source@linux.davincidsp.com; linux-
> m...@lists.infradead.org; dw...@infradead.org; t...@linutronix.de;
> a...@linux-
From: Chaithrika U S
Add ADV7343 I2C based video encoder driver. This follows the v4l2-subdev
framework. This driver has been tested on TI DM646x EVM. It has been tested for
Composite and Component outputs.
Updates as per review by Mauro Chehab, added support for more standards
supported
by the
From: Chaithrika U S
This patch adds driver for TI THS7303 video amplifier. This driver is
implemented as a v4l2 sub device. Tested on TI DM646x EVM.
This version has updates based on review comments by Mauro Chehab.
Signed-off-by: Chaithrika U S
Reviewed-by: Hans Verkuil
Signed-off-by: Hans
On Thu, 2009-05-07 at 09:50 +0800, Jeff wrote:
> Thanks for your suggestion. My test for audio stalls is not running from
> NFS(from local nand). What is the reference value of PBBPR register for
> DM355? Thanks.
check out this link.
http://e2e.ti.com/forums/p/4117/18643.aspx
I recall reading th
On Thursday 07 May 2009, vimal singh wrote:
> > Comments would be good, highlighting (a) byte 5 is reserved,
> > it's the manufacturer bad block marker, (b) 8 bytes @16 are
> > expected by JFFS2. Not everyone will "just know" those.
>
> How about leaving bytes '4' and '5' for bad block marker, to
Hi Andre
> IMP4VENC_LOW_QUALITY_HIGHEST_PERFORMANCE, however it doesn't seem to
> make any difference. When I compress these frames, it takes at least
> 12ms/frame, and more like 14 on average. In fact, no amount of fiddling
> with these parameters seems to make any difference at all.
14msec is s
I'm glad to see this patch is so small ... basically, just
adding a special case for 2K pages, and keeping the core of
this NAND driver the same. Not needing to change the 4-bit
ECC support from the patch I sent earlier seems a good sign.
Two comments though: (a) the board-dm355-evm.c file isn't
Hi Steve,
Thanks for the help. I got the McBSP0 working for my audio chip.
Other than the changes you suggested I had to disable the internal clock of
McBSP0.
Thanks a lot for your help.
Best Regards,
Azam.
___
Davinci-linux-open-source mailing list
D
21 matches
Mail list logo
