davincifb driver works only at reserver memory 120M-126M using ioremap
Hi, all. I change davincifb driver DMA buffer allocation from dma_alloc_coherent() into using ioremap() to reserver FB memory. If the reserve memory resides between 120M-126M, it works fine,while larger than 126M, its output is lines instead of linux tux. phys memory of my board is 256M, and pass mem=120M into bootargs. any thoughts? Regards, steven ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DMA Query on DM6446 CA
Hi, I have a doubt in DMA channel configuration. Is destination address or source address increments by the element index after ACPY3_start()? If so, is the increment is same as the element index? Plz reply ASAP. Regards, Padma ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
V4L2 and DM6446 resizer questions
Hi, I want to capture video from PAL cemera (4:2:2 format) by V4L2,and resize the video to 4:2:0 CIF format,there are two questions: 1,How to de-interlace two field as one frame and convert it to be CIF frame? I saw the EncodeDecode demo, which de-interlace directly with V4L2_FIELD_INTERLACED option.yet it doesn't resize the frame and convert 4:2:2 to 4:2:0. 2,Then I want to try the DM6446 resizer driver to conver. It seems that i have to read frame by V4L2 into mmaped DDR, and then using resizer to convert this frame buffer into a new output buffer. BUT The document TMS320DM644x DMSoC Video Processing Front End (VPFE) User's Guide said that there is a Video port interface (10−bit RAW) between CCDC and resizer,which means data should be transfered directly into resizer? Can anyone tell me how to use V4L2 and resizer driver to do that? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Flashing NAND for u-boot from Linux - ECC differences?
[Cc'ing Sergey who has been here before and might know more...] Troy Kisky wrote: Not only are the ECC bytes stored in different locations in the spare area, but the ECC value stored is also different. (davinci-git vs U-boot) I've modified both the linux kernel, and u-boot to store the ecc at the end of the spare bytes. But I haven't pushed this anywhere. It's pretty trivial to make U-Boot use the same ECC algorithm as the davinci-git tree. Maybe I don't understand it fully, but the current u-boot ECC implementation for large page NAND devices looks rather broken to me - it appears to generate a 12 byte ECC from the four NANDFnECC registers for a 2048 byte page read. But the NANDFnECC registers are for NAND chips on four different chip selects, not four 512-byte pages of one request. The data sheet says the ECC hardware will only work on 512-byte reads or writes. As I see it, if using ECC on large page devices on a single chip select, you have to pray that the other ECC registers are always in the same state. However, the MV kernel also does it this way, so maybe I'm missing something, or maybe they're both wrong? The git kernel appears to do the right thing, using the same NANDF1ECC register four times. Can show me how the current implementation in U-boot can work correctly at all? :) Thanks, Bernard. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Flashing NAND for u-boot from Linux - ECC differences?
Bernard Blackham wrote: [Cc'ing Sergey who has been here before and might know more...] Troy Kisky wrote: Not only are the ECC bytes stored in different locations in the spare area, but the ECC value stored is also different. (davinci-git vs U-boot) I've modified both the linux kernel, and u-boot to store the ecc at the end of the spare bytes. But I haven't pushed this anywhere. It's pretty trivial to make U-Boot use the same ECC algorithm as the davinci-git tree. Maybe I don't understand it fully, but the current u-boot ECC implementation for large page NAND devices looks rather broken to me - it appears to generate a 12 byte ECC from the four NANDFnECC registers for a 2048 byte page read. But the NANDFnECC registers are for NAND chips on four different chip selects, not four 512-byte pages of one request. The data sheet says the ECC hardware will only work on 512-byte reads or writes. You are 100% correct. The davinci u-boot implementation for 2048 byte pages is broken. /Thomas ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Flashing NAND for u-boot from Linux - ECC differences?
Thomas Lange wrote: Bernard Blackham wrote: Maybe I don't understand it fully, but the current u-boot ECC implementation for large page NAND devices looks rather broken to me - it appears to generate a 12 byte ECC from the four NANDFnECC registers for a 2048 byte page read. But the NANDFnECC registers are for NAND chips on four different chip selects, not four 512-byte pages of one request. The data sheet says the ECC hardware will only work on 512-byte reads or writes. You are 100% correct. The davinci u-boot implementation for 2048 byte pages is broken. Okay, thanks. I take it that means then that the MV kernel (at least at patch level 45) is also broken as it uses essentially the same code. I'm doing up a patch for u-boot with a config option to change the ECC layout to match Linux davinci git for 2k-page devices. I'm still struggling to see how the ECC layouts for 512-byte page devices compare between u-boot and Linux - the order of the bytes and the inversion of the bits to me says that even for 512-byte page devices, u-boot and git can't share ECCs. So my plan is to create a config option in u-boot (off by default for backwards compatibility) to make ECCs match git. Turning this option on will break compatibility with old u-boot and the MV kernel, but means that ECC correction will actually work for large page NAND. I just found that Troy has actually submitted a fix for this previously[1], but it was amalgamated with other changes that led to it being nacked. A bit of a shame, because it was good work! Anyway, I hope to have a well tested patch tomorrow! Cheers, Bernard. [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/32017 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Flashing NAND for u-boot from Linux - ECC differences?
Bernard Blackham wrote: I just found that Troy has actually submitted a fix for this previously[1], but it was amalgamated with other changes that led to it being nacked. A bit of a shame, because it was good work! Thanks, but I actually stopped pushing the patch because I agreed that the Linux kernel should be fixed first. A little heated debate would not have made me give up. Now that the davinci-git kernel is fixed, I'm glad your willing to do this. Thanks Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davincifb driver works only at reserver memory 120M-126M usingioremap
Are you using CMEM? Typically, CMEM is configured (during 'insmod', usually from the loadmodules.sh script) to use 120MB - 128 MB. Regards, - Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of steven.zhang Sent: Thursday, June 26, 2008 1:33 AM To: davinci Cc: torran; [EMAIL PROTECTED] Subject: davincifb driver works only at reserver memory 120M-126M usingioremap Hi, all. I change davincifb driver DMA buffer allocation from dma_alloc_coherent() into using ioremap() to reserver FB memory. If the reserve memory resides between 120M-126M, it works fine,while larger than 126M, its output is lines instead of linux tux. phys memory of my board is 256M, and pass mem=120M into bootargs. any thoughts? Regards, steven ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: dm355: Running the demos
Sorry but I'm extremely new to Linux and DaVinci but would this have anything to do with me not booting the new kernel after I built it and rebuilt the DVEVM software for the target? Tivy, Robert wrote: This sounds like you need to rebuild dm350mmap.ko against the kernel that you're booting. The message disagrees about version of symbol ... usually results from building a .ko against a kernel different than that which is being booted. Regards, - Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Anthony Gutierrez Sent: Wednesday, June 25, 2008 9:20 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: dm355: Running the demos I am trying to run the venc demo for the dm355, when I try to run loadmodules.sh I get the following: [EMAIL PROTECTED]:~# cd /opt/dvsdk/dm355/ [EMAIL PROTECTED]:/opt/dvsdk/dm355# ./loadmodules.sh ioremap_nocache(0x8740, 12582912)=0xc788 allocated heap buffer 0xc788 of size 0xce000 cmem initialized 8 pools between 0x8740 and 0x8800 dm350mmap: disagrees about version of symbol davinci_request_dma dm350mmap: Unknown symbol davinci_request_dma insmod: error inserting 'dm350mmap.ko': -1 Unknown symbol in module mknod: wrong number of arguments Try `mknod --help' for more information. [EMAIL PROTECTED]:/opt/dvsdk/dm355# Also is it necessary to boot the new kernel once it's built? To run the demos or to do anything else? -Anthony ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
IP network camera reference design
Has anyone tried this product, mentioned here? http://focus.ti.com/apps/docs/mrktgenpage.tsp?contentId=41246appId=79DCMP=DSP_IPNetcamHQS=Other+OT+ipnetcampr Our main interest is in white balance/exposure controls. Does anyone have any pointers for these? Chris ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Re: Re: Re: RE: Buggy Audio Driver
Andy Ngo,Andrew Armstrong，你好
really? I will do more test.
[EMAIL PROTECTED]
2008-06-27
- Original Message -
From: Andy Ngo
To: jp_liu,Andrew Armstrong
Sent: 2008-06-26, 10:25:07
Subject: Re: Re: Re: RE: Buggy Audio Driver
JP,
I tried your fix and the write stall still occurs under heavy system
load (I forced the CPU to be utilized heavily as a test case to induce the
write stall). Hence the
fix you suggested didn't work for us since our system can be under
heaving load during usage. How did you come to the solution you suggested? Why
does switching the order of AUDIO_INCREMENT_HEAD(s) and audio_stop_dma(s) help?
Actually, when trying your suggestion, we actually got more write stalls in a
fixed period.
Anyways, I think I may be coming up to something with this write stall issue.
The change below is what I tried and it looks promising (I ran my heaving
system stress test for 3 hours and not a write stall has occurred yet, usually
I would get 3-5 stalls already); I'll let it run overnight to see if I no write
stall occurs (I have an infinite audio loopback test that reads from the device
and plays it back to the device, while other heaving processing is going on).
Just by trial and error, I uncommented the code to the 2 DMA_START calls in
audio_stop_dma (davinci-audio-dma-intfc.c):
Change
void audio_stop_dma(audio_stream_t * s)
{
...
if (s-spin_idle) {
#if 0
DMA_START(s, SPIN_ADDR, SPIN_SIZE);
DMA_START(s, SPIN_ADDR, SPIN_SIZE);
#endif
s-dma_spinref = 2;
} else
...
}
to
void audio_stop_dma(audio_stream_t * s)
{
...
if (s-spin_idle) {
#if 1
davinci_start_sound_dma(s, SPIN_ADDR, SPIN_SIZE);
davinci_start_sound_dma(s, SPIN_ADDR, SPIN_SIZE);
#endif
s-dma_spinref = 2;
} else
...
}
I looked at the other drivers in the oss directory and some have these
commented DMA_START calls enabled so I wonder why it was commented out for this
board. It's good so far (usually I would have 3-5 stalls in the 3-hour period I
have run the test). I'm keeping my fingers crossed.
JP, when you switch to McASP as the master, you need to adjust the J-value,
D-values 8-MSBs and 6-MSBs based on the clock to your AIC33 codec you're
using.. For the DVEVM, the clock is 22Mhz (#define MCLK 22), so the J-value,
D-values 8-MSBs and 6-MSBs values you see in davinci_set_samplerate
(davinci-audio-aic33.c) is based on this clock. For our system, the MCLK is
actually 22.588 Mhz so I adjusted the J-value, D-values 8-MSBs and 6-MSBs for
the sample rate I'm using (8Khz) and it works fine; I had weird sounds like you
did until I adjusted the J-value, D-values 8-MSBs and 6-MSBs; took me a while
to figure it out.
For those willing to try out what I did, please let the forum know if it fixes
your write stall problems. Thanks.
Regards,
Andy
- Original Message
From: jp_liu [EMAIL PROTECTED]
To: Andrew Armstrong [EMAIL PROTECTED]
Cc: davinci-linux-open-source davinci-linux-open-source@linux.davincidsp.com
Sent: Wednesday, June 25, 2008 6:41:07 PM
Subject: Re: Re: Re: RE: Buggy Audio Driver
Sounds good! If got any new info about it, Dont forget to tell me.
- Original Message -
From: Andrew Armstrong
Cc: davinci-linux-open-source
Sent: Wednesday, June 25, 2008 7:14 PM
Subject: Re: Re: Re: RE: Buggy Audio Driver
Guys,
I tried jp_liu's suggested kernel fix, however I left my AIC33 as
MASTER, and it seems to be running without locking up. Cheers JP!
On a side note, I never really got the McASP to work as a master
successfully, but I did not bother digging around for the cause.
Thanks for all your help, I will probably revisit this in the near
future.
Best Regards,
Andrew
On Wed, 2008-06-25 at 11:19 +0800, jp_liu wrote:
Andy Ngo,Andrew Armstrong,PQuiney,davinci-linux-open-source,
yes, I changed it base david's version(btw, thanks david). the sound
is bad because commented out if (AUDIO_QUEUE_LAST(s)){ ... } in
function sound_dma_irq_handler().
but another issue is cannot set clock-rate to 8000 when using the
McASP as the master, it is so bad.
I think set which is master is not the point to caused the problem,
but I have not confirm it yet.
[EMAIL PROTECTED]
2008-06-25
- Original Message -
From: Andy Ngo
To: jp_liu,Andrew Armstrong,PQuiney,davinci-linux-open-source
Sent: 2008-06-25, 11:11:47
Subject: Re: Re: RE: Buggy Audio Driver
Thanks, jp_liu. I will try that out. This is similarly to
David Conrad's initial breakthrough post a while back but it
sounds promising.. By the way, I too am using the McASP as the
master and not the AIC33 codec.
Regards,
Andy
- Original Message
From: jp_liu
To: Andy Ngo ; Andrew Armstrong
; PQuiney
; davinci-linux-open-source
Sent: Tuesday, June 24, 2008 7:25:08 PM
Subject: Re: Re: RE: Buggy Audio Driver
Andy Ngo,Andrew
RE: davincifb driver works only at reserver memory 120M-126M usingioremap
Thanks Rob. But I am afraid not. You know, when FB driver is loading(on kernel booting), CMEM is not insmod(after kernel boot up) at all. Regards, Steven On Thu, 2008-06-26 at 16:41 -0500, Tivy, Robert wrote: Are you using CMEM? Typically, CMEM is configured (during 'insmod', usually from the loadmodules.sh script) to use 120MB - 128 MB. Regards, - Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of steven.zhang Sent: Thursday, June 26, 2008 1:33 AM To: davinci Cc: torran; [EMAIL PROTECTED] Subject: davincifb driver works only at reserver memory 120M-126M usingioremap Hi, all. I change davincifb driver DMA buffer allocation from dma_alloc_coherent() into using ioremap() to reserver FB memory. If the reserve memory resides between 120M-126M, it works fine,while larger than 126M, its output is lines instead of linux tux. phys memory of my board is 256M, and pass mem=120M into bootargs. any thoughts? Regards, steven ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davincifb driver works only at reserver memory 120M-126M usingioremap
There's a silicon errata that may be applicable - not sure. Advisory 1.3.1 here: http://focus.ti.com/lit/er/sprz241k/sprz241k.pdf ... states that the OSD window addressing is limited to 128 MB. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of steven.zhang Sent: Thursday, June 26, 2008 8:31 PM To: Tivy, Robert Cc: torran; davinci; [EMAIL PROTECTED] Subject: RE: davincifb driver works only at reserver memory 120M-126M usingioremap Thanks Rob. But I am afraid not. You know, when FB driver is loading(on kernel booting), CMEM is not insmod(after kernel boot up) at all. Regards, Steven On Thu, 2008-06-26 at 16:41 -0500, Tivy, Robert wrote: Are you using CMEM? Typically, CMEM is configured (during 'insmod', usually from the loadmodules.sh script) to use 120MB - 128 MB. Regards, - Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of steven.zhang Sent: Thursday, June 26, 2008 1:33 AM To: davinci Cc: torran; [EMAIL PROTECTED] Subject: davincifb driver works only at reserver memory 120M-126M usingioremap Hi, all. I change davincifb driver DMA buffer allocation from dma_alloc_coherent() into using ioremap() to reserver FB memory. If the reserve memory resides between 120M-126M, it works fine,while larger than 126M, its output is lines instead of linux tux. phys memory of my board is 256M, and pass mem=120M into bootargs. any thoughts? Regards, steven ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH RFC] ARM: Davinci: NAND fix for large page ECC and linux compatibility
U-boot's HW ECC support for large page NAND on Davinci is completely
broken. Some kernels, such as the 2.6.10 one supported by
MontaVista for Davinci, rely upon this broken behaviour as they
share the same code for ECCs. In the existing scheme, error
detection *might* work on large page, but error correction
definitely does not. Small page ECC correction works, but the
format is not compatible with the mainline git kernel.
This patch adds ECC code that matches what is currently in the
Davinci git repository (since NAND support was added in 2.6.24).
This makes the ECC and OOB layout written by u-boot compatible with
Linux for both small page and large page devices and fixes ECC
correction for large page devices.
The code depends on a #define CFG_LINUX_COMPATIBLE_ECC, which is
undefined by default, making the default state backwards compatible.
I have verified this by compiling without the #define and producing
a binary byte-for-byte identical to one without this patch.
[NOTE: I have not yet been able to get my hands on a board with
small-page NAND to test, but large page does work. If anybody is
interested in testing it, please do and let me know if it works for
you (i.e. uboot with this patch and davinci git kernel can
read/write the same NAND).]
Signed-off-by: Bernard Blackham [EMAIL PROTECTED]
---
cpu/arm926ejs/davinci/nand.c| 79 ++--
include/configs/davinci_dvevm.h | 12 ++
2 files changed, 89 insertions(+), 2 deletions(-)
Index: u-boot-1.3.3/cpu/arm926ejs/davinci/nand.c
===
--- u-boot-1.3.3.orig/cpu/arm926ejs/davinci/nand.c 2008-05-19
18:47:11.0 +0800
+++ u-boot-1.3.3/cpu/arm926ejs/davinci/nand.c 2008-06-27 13:04:03.0
+0800
@@ -87,6 +87,10 @@ static void nand_davinci_select_chip(str
}
#ifdef CFG_NAND_HW_ECC
+
+#ifndef CFG_LINUX_COMPATIBLE_ECC
+/* Linux-compatible ECC uses MTD defaults. */
+/* These layouts are not compatible with Linux or RBL/UBL. */
#ifdef CFG_NAND_LARGEPAGE
static struct nand_oobinfo davinci_nand_oobinfo = {
.useecc = MTD_NANDECC_AUTOPLACE,
@@ -104,6 +108,7 @@ static struct nand_oobinfo davinci_nand_
#else
#error Either CFG_NAND_LARGEPAGE or CFG_NAND_SMALLPAGE must be defined!
#endif
+#endif
static void nand_davinci_enable_hwecc(struct mtd_info *mtd, int mode)
{
@@ -141,12 +146,29 @@ static u_int32_t nand_davinci_readecc(st
static int nand_davinci_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
u_char *ecc_code)
{
+#ifdef CFG_LINUX_COMPATIBLE_ECC
+ unsigned int ecc_val = nand_davinci_readecc(mtd, 1);
+ /* squeeze 0 middle bits out so that it fits in 3 bytes */
+ unsigned int tmp = (ecc_val0x0fff)|((ecc_val0x0fff)4);
+ /* invert so that erased block ecc is correct */
+ tmp = ~tmp;
+ ecc_code[0] = (u_char)(tmp);
+ ecc_code[1] = (u_char)(tmp 8);
+ ecc_code[2] = (u_char)(tmp 16);
+#else
u_int32_t tmp;
int region, n;
struct nand_chip*this = mtd-priv;
n = (this-eccmode == NAND_ECC_HW12_2048) ? 4 : 1;
+ /*
+* This is not how you should read ECCs on large page Davinci devices.
+* The region parameter gets you ECCs for flash chips on different chip
+* selects, not the 4x512 byte pages in a 2048 byte page.
+*
+* Preserved for backwards compatibility though.
+*/
region = 1;
while (n--) {
tmp = nand_davinci_readecc(mtd, region);
@@ -155,9 +177,51 @@ static int nand_davinci_calculate_ecc(st
*ecc_code++ = ((tmp 8) 0x0f) | ((tmp 20) 0xf0);
region++;
}
+#endif
+
return(0);
}
+#ifdef CFG_LINUX_COMPATIBLE_ECC
+static int nand_davinci_correct_data(struct mtd_info *mtd, u_char *dat,
+ u_char *read_ecc, u_char *calc_ecc)
+{
+ struct nand_chip *chip = mtd-priv;
+ u_int32_t ecc_nand = read_ecc[0] | (read_ecc[1] 8) |
+ (read_ecc[2] 16);
+ u_int32_t ecc_calc = calc_ecc[0] | (calc_ecc[1] 8) |
+ (calc_ecc[2] 16);
+ u_int32_t diff = ecc_calc ^ ecc_nand;
+
+ if (diff) {
+ if diff12)^diff) 0xfff) == 0xfff) {
+ /* Correctable error */
+ if ((diff(12+3)) chip-eccsize) {
+ uint8_t find_bit = 1 ((diff12)7);
+ uint32_t find_byte = diff(12+3);
+ dat[find_byte] ^= find_bit;
+ DEBUG (MTD_DEBUG_LEVEL0, Correcting single bit
ECC error at offset: %d, bit: %d\n, find_byte, find_bit);
+ return 1;
+ } else {
+ return -1;
+ }
+ } else if
