Re: Create a large file on mmc card

[Arie de Muijnck]

From: tabbaa najim
I am using the dm6446 kit board and i want to create a big file quickly in 
my application.
Do you think that it is possible without modifying the mmc driver or the 
FAT file sustem?
if the only solution is to modify the FAT fs (I am thinking of using ioctl 
command and add a function in the kernel to create a big file without 
writing data to the mmc card by modifuing only the FAT tables), could you 
give me some explication on how it can be done.



I would try the following: Open a file for random writing, do an lseek to a
position at 1.8GB, write one byte, close the file.

Regards,
Arie de Muijnck


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: nand_programmer check all nand flash blocks error

[JitendraJain]

Hi Duke Zuo,

We are also struggling with similar issue since few weeks. We have done
some investigation that might help you.

 

1. What NAND chip you are using? 

2. What is the page size? As per TI, RBL does not support NAND having
4096 page size 

3. Are you able to do UART boot? 

4. Have you modified anything in NAND_Programmer.pjt source code? If
yes, what are those? 

5. It is surprising to see your changes related to ALE/CMD address, we
are not required to do so.

 

Regards,

Jitendra

 

 



From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
Behalf Of zuowenping

Sent: Wednesday, February 11, 2009 12:55 PM

To: davinci-linux-open-source

Subject: nand_programmer check all nand flash blocks error

 

dear all:

I use a new nand flash for dm355 in my new borad,first i used Micron
1G nand flash, the address have been modify:

#define NAND_ALE_ADDR ((volatile Uint8*)0x0204)  //from
0x0208

#define NAND_CMD_ADDR ((volatile Uint8*)0x0208)  //from
0x0210

if i use the old address, the Manufacture id and device id is always
0 when read it.and the hardware told me to modify the address!but when I
run the programmer by jtag,the result is:

Started Nand programming

 Manufacture ID 2c

 device ID d3

 find the NAND device in the table!

NANDInit() Successful

Enter the UBL File Name

 
D:\dvsdk_1_30_00_40\dvsdk_1_30_00_40\PSP_01_20_00_014\bin\dm355\ublDM355
-nand.bin

 Block number 0 is a BAD BLOCKBlock 0 is a bad block

 Block number 1 is a BAD BLOCKBlock 1 is a bad block

 Block number 2 is a BAD BLOCKBlock 2 is a bad block

 Block number 3 is a BAD BLOCKBlock 3 is a bad block

 Block number 4 is a BAD BLOCKBlock 4 is a bad block

 Block number 5 is a BAD BLOCKBlock 5 is a bad block

 Block number 6 is a BAD BLOCKBlock 6 is a bad block

 Block number 7 is a BAD BLOCKBlock 7 is a bad block

 Block number 8 is a BAD BLOCKBlock 8 is a bad block

 Block number 9 is a BAD BLOCKBlock 9 is a bad block

 Block number 10 is a BAD BLOCKBlock 10 is a bad block

 Block number 11 is a BAD BLOCKBlock 11 is a bad block

 Block number 12 is a BAD BLOCKBlock 12 is a bad block

 Block number 13 is a BAD BLOCKBlock 13 is a bad block

 Block number 14 is a BAD BLOCKBlock 14 is a bad block

 Block number 15 is a BAD BLOCKBlock 15 is a bad block

 Block number 16 is a BAD BLOCKBlock 16 is a bad block

 Block number 17 is a BAD BLOCKBlock 17 is a bad block

 Block number 18 is a BAD BLOCKBlock 18 is a bad block

 Block number 19 is a BAD BLOCKBlock 19 is a bad block

 Block number 20 is a BAD BLOCKBlock 20 is a bad block

 .

 It seemd all block is bad!!

 When i skip the block checking(just return E_PASS in
NANDCheckBadBlock() function ),it can run ok,the ubl and uboot seems
burning ok,but when i reboot the board,it cann't boot!!

 I have contact to the supporter by ti,they told me the RBL(rom boot
loader) can't support 128 pages of a block,so i changed a nand flash
type HY27UG088G whick 64 pages of a block,it seem the same result! 

 any one can help me?thanks a lot!! 

2009-02-11 



duke zuo

da-li tech in hangzhou of china

___
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: nand_programmer check all nand flash blocks error

[zuowenping]

1:first i use the nand flash type is MT29F8G08MAAWC,if i cann't modify the 
address,the  Manufacture  and device id is always 0,and the hardware engineer 
told me to modify it,then the id can be identify ok.when i change nand flash 
type to HY27UG088 ,the same result it is!
2:the micron flash page size is 2048+64,and the HY27UG088 is also size.
3:we can do uart boot and i have test it ok,but i have xds560 emluator,it can 
translate data easy!
4:if i use the MT29F8G08M,i have to add {0xD3, 128,  2048+64,23, 5},  
/* Micron  MT29F8G08AAA */ //add by duke 2009.2.9 
item in the const NAND_DEVICE_INFO   gNandDevInfo[] 
5:I am surprising too,but the hardware engineer ask me to do it.


2009-02-11 



zuowenping 



发件人： jitendraj...@emerson.com 
发送时间： 2009-02-11  16:12:50 
收件人： zuowenp...@dali-tech.com; davinci-linux-open-source@linux.davincidsp.com 
抄送： 
主题： RE: nand_programmer check all nand flash blocks error 
 
Hi Duke Zuo,
We are also struggling with similar issue since few weeks. We have done some 
investigation that might help you.
 
1. What NAND chip you are using? 
2. What is the page size? As per TI, RBL does not support NAND having 4096 page 
size 
3. Are you able to do UART boot? 
4. Have you modified anything in “NAND_Programmer.pjt” source code? If yes, 
what are those? 
5. It is surprising to see your changes related to ALE/CMD address, we are not 
required to do so.
 
Regards,
Jitendra
 
 

From: davinci-linux-open-source-boun...@linux.davincidsp.com 
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of 
zuowenping
Sent: Wednesday, February 11, 2009 12:55 PM
To: davinci-linux-open-source
Subject: nand_programmer check all nand flash blocks error
 
dear all:
I use a new nand flash for dm355 in my new borad,first i used Micron 1G 
nand flash, the address have been modify:
#define NAND_ALE_ADDR ((volatile Uint8*)0x0204)  //from 0x0208
#define NAND_CMD_ADDR ((volatile Uint8*)0x0208)  //from 0x0210
if i use the old address, the Manufacture id and device id is always 0 when 
read it.and the hardware told me to modify the address!but when I run the 
programmer by jtag,the result is:
Started Nand programming
 Manufacture ID 2c
 device ID d3
 find the NAND device in the table!
NANDInit() Successful
Enter the UBL File Name

D:\dvsdk_1_30_00_40\dvsdk_1_30_00_40\PSP_01_20_00_014\bin\dm355\ublDM355-nand.bin
 Block number 0 is a BAD BLOCKBlock 0 is a bad block
 Block number 1 is a BAD BLOCKBlock 1 is a bad block
 Block number 2 is a BAD BLOCKBlock 2 is a bad block
 Block number 3 is a BAD BLOCKBlock 3 is a bad block
 Block number 4 is a BAD BLOCKBlock 4 is a bad block
 Block number 5 is a BAD BLOCKBlock 5 is a bad block
 Block number 6 is a BAD BLOCKBlock 6 is a bad block
 Block number 7 is a BAD BLOCKBlock 7 is a bad block
 Block number 8 is a BAD BLOCKBlock 8 is a bad block
 Block number 9 is a BAD BLOCKBlock 9 is a bad block
 Block number 10 is a BAD BLOCKBlock 10 is a bad block
 Block number 11 is a BAD BLOCKBlock 11 is a bad block
 Block number 12 is a BAD BLOCKBlock 12 is a bad block
 Block number 13 is a BAD BLOCKBlock 13 is a bad block
 Block number 14 is a BAD BLOCKBlock 14 is a bad block
 Block number 15 is a BAD BLOCKBlock 15 is a bad block
 Block number 16 is a BAD BLOCKBlock 16 is a bad block
 Block number 17 is a BAD BLOCKBlock 17 is a bad block
 Block number 18 is a BAD BLOCKBlock 18 is a bad block
 Block number 19 is a BAD BLOCKBlock 19 is a bad block
 Block number 20 is a BAD BLOCKBlock 20 is a bad block
 .
 It seemd all block is bad!!
 When i skip the block checking(just return E_PASS in NANDCheckBadBlock() 
function ),it can run ok,the ubl and uboot seems burning ok,but when i reboot 
the board,it cann't boot!!
 I have contact to the supporter by ti,they told me the RBL(rom boot 
loader) can't support 128 pages of a block,so i changed a nand flash type 
HY27UG088G whick 64 pages of a block,it seem the same result! 
 any one can help me?thanks a lot!! 
2009-02-11 

duke zuo
da-li tech in hangzhou of china
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Gstreamer:video OK audio problem

[zhenfeng ren]

hello,everyone:

I download gstreamer from:
  http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100

When I run test_AVI.sh, video is OK.  I have tested some AVI
files.Some files only first few seconds audio is OK(about 2 second ?),
then no sound. Some files there is no sound at all.
Anyone give me some suggestion?

-- 
Thanks,
Zhenfeng Ren

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Gamma correction in VENC

[zuowenping]

the dm355 only can supply 16 bit rgb,so the ths8200 dman_cntl register must 
modify to 0x71,not default 0x70!


2009-02-11 



zuowenping 



发件人： Lori 
发送时间： 2009-02-11  14:07:07 
收件人： davinci-linux-open-source@linux.davincidsp.com 
抄送： 
主题： Gamma correction in VENC 
 
Dear all:

I am using the ths8200 to output VGA format signal, so the dm355 must supply 
the RGB656 format. But in this situation the display on monitor lost some color 
gradation. The venc provides the gamma correction. I want konw if it is useful 
for my problem. And the gamma correction use only two register, who can give me 
an example or advice about how to use them in program? 
___
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: nand_programmer check all nand flash blocks error

[JitendraJain]

Hi Zuo,

Could you pls elaborate more on “change nand flash type to HY27UG088”?

Are you physically changing the NAND flash or doing software changes?

 

Also when you skip the NANDCheckBadBlock () function, you said the ubl and 
uboot seems burning ok, but when you reboot the board, it can’t boot!!

So can you read 32 bits of ARM internal memory (0x7ffc-0x8000) via JTAG and let 
us know what you are getting.

 

Regards,

Jitendra



From: zuowenping [mailto:zuowenp...@dali-tech.com] 
Sent: Wednesday, February 11, 2009 2:06 PM
To: Jain, Jitendra [PROTOOL/RTC/IN]; davinci-linux-open-sou...@linux.
Subject: Re: RE: nand_programmer check all nand flash blocks error

 

1:first i use the nand flash type is MT29F8G08MAAWC,if i cann't modify the 
address,the  Manufacture  and device id is always 0,and the hardware engineer 
told me to modify it,then the id can be identify ok.when i change nand flash 
type to HY27UG088 ,the same result it is!

2:the micron flash page size is 2048+64,and the HY27UG088 is also size.

3:we can do uart boot and i have test it ok,but i have xds560 emluator,it can 
translate data easy!

4:if i use the MT29F8G08M,i have to add {0xD3, 128,  2048+64,23, 5},  
/* Micron  MT29F8G08AAA */ //add by duke 2009.2.9 

item in the const NAND_DEVICE_INFO   gNandDevInfo[] 

5:I am surprising too,but the hardware engineer ask me to do it.

 

 

2009-02-11 



zuowenping 



发件人： jitendraj...@emerson.com 

发送时间： 2009-02-11  16:12:50 

收件人： zuowenp...@dali-tech.com; davinci-linux-open-source@linux.davincidsp.com 

抄送： 

主题： RE: nand_programmer check all nand flash blocks error 

Hi Duke Zuo,

We are also struggling with similar issue since few weeks. We have done some 
investigation that might help you.

 

1. What NAND chip you are using? 

2. What is the page size? As per TI, RBL does not support NAND having 4096 page 
size 

3. Are you able to do UART boot? 

4. Have you modified anything in “NAND_Programmer.pjt” source code? If yes, 
what are those? 

5. It is surprising to see your changes related to ALE/CMD address, we are not 
required to do so.

 

Regards,

Jitendra

 

 



From: davinci-linux-open-source-boun...@linux.davincidsp.com 
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of 
zuowenping

Sent: Wednesday, February 11, 2009 12:55 PM

To: davinci-linux-open-source

Subject: nand_programmer check all nand flash blocks error

 

dear all:

I use a new nand flash for dm355 in my new borad,first i used Micron 1G 
nand flash, the address have been modify:

#define NAND_ALE_ADDR ((volatile Uint8*)0x0204)  //from 0x0208

#define NAND_CMD_ADDR ((volatile Uint8*)0x0208)  //from 0x0210

if i use the old address, the Manufacture id and device id is always 0 when 
read it.and the hardware told me to modify the address!but when I run the 
programmer by jtag,the result is:

Started Nand programming

 Manufacture ID 2c

 device ID d3

 find the NAND device in the table!

NANDInit() Successful

Enter the UBL File Name


D:\dvsdk_1_30_00_40\dvsdk_1_30_00_40\PSP_01_20_00_014\bin\dm355\ublDM355-nand.bin

 Block number 0 is a BAD BLOCKBlock 0 is a bad block

 Block number 1 is a BAD BLOCKBlock 1 is a bad block

 Block number 2 is a BAD BLOCKBlock 2 is a bad block

 Block number 3 is a BAD BLOCKBlock 3 is a bad block

 Block number 4 is a BAD BLOCKBlock 4 is a bad block

 Block number 5 is a BAD BLOCKBlock 5 is a bad block

 Block number 6 is a BAD BLOCKBlock 6 is a bad block

 Block number 7 is a BAD BLOCKBlock 7 is a bad block

 Block number 8 is a BAD BLOCKBlock 8 is a bad block

 Block number 9 is a BAD BLOCKBlock 9 is a bad block

 Block number 10 is a BAD BLOCKBlock 10 is a bad block

 Block number 11 is a BAD BLOCKBlock 11 is a bad block

 Block number 12 is a BAD BLOCKBlock 12 is a bad block

 Block number 13 is a BAD BLOCKBlock 13 is a bad block

 Block number 14 is a BAD BLOCKBlock 14 is a bad block

 Block number 15 is a BAD BLOCKBlock 15 is a bad block

 Block number 16 is a BAD BLOCKBlock 16 is a bad block

 Block number 17 is a BAD BLOCKBlock 17 is a bad block

 Block number 18 is a BAD BLOCKBlock 18 is a bad block

 Block number 19 is a BAD BLOCKBlock 19 is a bad block

 Block number 20 is a BAD BLOCKBlock 20 is a bad block

 .

 It seemd all block is bad!!

 When i skip the block checking(just return E_PASS in NANDCheckBadBlock() 
function ),it can run ok,the ubl and uboot seems burning ok,but when i reboot 
the board,it cann't boot!!

 I have contact to the supporter by ti,they told me the RBL(rom boot 
loader) can't support 128 pages of a block,so i changed a nand flash type 
HY27UG088G whick 64 

AW: Gstreamer:video OK audio problem

[DISTEC Kloiber Thomas]

Hello,

the Gstreamer version you are using is quite outdated.

I recommend to use this version 

https://gstreamer.ti.com/gf/project/gstreamer_ti/wiki/

Best regards
Thomas


-Ursprüngliche Nachricht-
Von: zhenfeng ren [mailto:1985re...@gmail.com] 
Gesendet: Mittwoch, 11. Februar 2009 09:40
An: Davinci-linux-open-source@linux.davincidsp.com
Betreff: Gstreamer:video OK audio problem

hello,everyone:

I download gstreamer from:
  http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100

When I run test_AVI.sh, video is OK.  I have tested some AVI files.Some files 
only first few seconds audio is OK(about 2 second ?), then no sound. Some files 
there is no sound at all.
Anyone give me some suggestion?

--
Thanks,
Zhenfeng Ren



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: Dsplink.dsp?

[Ryan Talbot]

Hey guys,

I'm now getting a linker error while building the server.  It says that
_DDR2 is an undefined symbol, coming from dsplink.lib.  I guess this is
because I am now using DSPLink 1.60 instead of 1.30, but I can't find
any information on this _DDR2 symbol.  Does anybody know what it means
or what it should be?

I also could not find the BIOSUtils package anywhere as a standalone
download.  I ended up creating a symbolic 'bios' link that resides in
codec_engine_2_21/packages/ti that points to
codec_engine_2_21/cetools/packages/ti/bios, because otherwise the
compilation would fail saying that it couldn't find the package
ti.bios.utils.

You guys have been a great help, thanks!
Ryan 

 -Original Message-
 From: David Chan [mailto:blacksword.da...@gmail.com] 
 Sent: Tuesday, February 10, 2009 9:04 AM
 To: Ryan Talbot
 Cc: Griffis, Brad; davinci-linux-open-source@linux.davincidsp.com
 Subject: Re: Dsplink.dsp?
 
 Ryan,
 
 It's seems that you are not using the DVSDK2.0EA edition. I 
 think that you will meet another roadblock as I have meet.
 
 If the codec is not developed by your own team, you will find 
 that the Codec is not compatible the dsplink 1.50 or later.
 (Video_copy can run, but the codec server from current codecs 
 will crashed the kernel! This is why my personal release of 
 CE2.21 based on my toolchain is delayed)
 
 Just got the mail from TI, that new codecs are Fedexed to me. 
 But until now, I don't know where are them. Trying tracking them now!
 
 The best now seems to be dsplink1.4 with mv50 (or my 
 toolchain) and new kernel .
 
 David
 On Feb 10, 2009, at 2:08 PM, Ryan Talbot wrote:
 
  Thanks, Brad, that seems to have cleared that roadblock.  I hadn't 
  noticed that difference between the two releases... 
 downloading each 
  component separately really is proving to be a pain.
 
  David, thanks again for your input earlier; I was in the process of 
  implementing it when Brad's solution showed up in my inbox 
 and did the 
  trick.
 
  Ryan
 
  -Original Message-
  From: davinci-linux-open-source-boun...@linux.davincidsp.com
  [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
  ] On Behalf Of Griffis, Brad
  Sent: Monday, February 09, 2009 10:06 PM
  To: Ryan Talbot; davinci-linux-open-source@linux.davincidsp.com
  Subject: RE: Dsplink.dsp?
 
  This path is likely incorrect:
 
  /home/rtalbot/dvevm_2_21/dsplink_1_60/packages
 
  You need to do one of the following to fix it:
 
  1)  Root through the various makefiles to figure out where they 
  define XDCPATH and delete the extra packages they are 
 appending to 
  the dsplink path.
 
  - OR -
 
  2)  Add a packages folder in between the dsplink_1_60
  folder and the dsplink folder.  (This is probably the
  quickest/easiest.)
 
  I think this all came about because there is a CONVENTION at TI to 
  put all the RTSC packages of a product into a directory called 
  packages.  DSPLink does not follow this convention and the DVSDK 
  tried to force the convention upon DSPLink.  So in the version of 
  dsplink that is delivered with the DVSDK they created that extra 
  directory called packages so it would follow the same 
 convention as 
  everything else.  It makes everything look uniform, but it 
 can be a 
  real pain in the rear if you try to use a freshly 
 downloaded version 
  of dsplink.
 
  Brad
 
  -Original Message-
  From: davinci-linux-open-source-boun...@linux.davincidsp.com
  
 [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On 
  Behalf Of Ryan Talbot
  Sent: Saturday, February 07, 2009 2:01 AM
  To: davinci-linux-open-source@linux.davincidsp.com
  Subject: Dsplink.dsp?
 
  Hi folks,
 
  I feel that I must have missed something simple, but I
  can't for the
  life of me figure out what it was.  I followed the
  directions to build
  the DSP side of DSPLink that are outlined here:
  http://tiexpressdsp.com/wiki/index.php?title=Building_DSPLink
  ...including the instructions for the XDC integration.
 
  I received no errors on build.  However, when I got to
  building a 3rd
  party server, I get the following error:
 
  js:
 
  
 /home/rtalbot/dvevm_2_21/xdctools_3_10_03/packages/xdc/cfg/Main.xs,
  line 201: xdc.services.global.XDCException: xdc.PACKAGE_NOT_FOUND:
  can't locate the package 'dsplink.dsp' along the path:
 
  '/home/rtalbot/dvevm_2_21;/home/rtalbot/dvevm_2_21/
  codec_servers_1_23/
  pa
 
  ckages;/home/rtalbot/dvevm_2_21/codec_engine_2_21/packages;/home/
  rtalb
  ot
 
  /dvevm_2_21/dsplink_1_60/packages;/home/rtalbot/dvevm_2_21/
  xdais_6_21/
  pa
 
  ckages;/home/rtalbot/dvevm_2_21/linuxutils_2_21/packages;/home/
  rtalbot
  /d
 
  vevm_2_21/bios_5_33_02/packages;/home/rtalbot/dvevm_2_21/
  framework_com
  po
 
  nents_2_21/packages;/home/rtalbot/dvevm_2_21/xdctools_3_10_03/
  packages;.
  ./../..;'. Ensure that the package path is set correctly.
 
  I called the base directory 'dvevm_2_21' for lack of any
  better name
  for the hodge-podge of 

Re: RE: nand_programmer check all nand flash blocks error

[Steve Chen]

Try sending a reset command before using it.  Micron NAND FLASH comes up
in low power state, and you won't be able to access the FLASH in that
state.  This was the solution used by one of our engineers to resolve
Micron NAND FLASH issues a few weeks ago.

Regards,

Steve

On Wed, 2009-02-11 at 16:36 +0800, zuowenping wrote:
 1:first i use the nand flash type is MT29F8G08MAAWC,if i cann't modify
 the address,the  Manufacture  and device id is always 0,and the
 hardware engineer told me to modify it,then the id can be identify
 ok.when i change nand flash type to HY27UG088 ,the same result it is!
 2:the micron flash page size is 2048+64,and the HY27UG088 is also
 size.
 3:we can do uart boot and i have test it ok,but i have xds560
 emluator,it can translate data easy!
 4:if i use the MT29F8G08M,i have to add {0xD3, 128,  2048
 +64,23, 5},  /* Micron  MT29F8G08AAA */ //add by duke 2009.2.9 
 item in the const NAND_DEVICE_INFO   gNandDevInfo[] 
 5:I am surprising too,but the hardware engineer ask me to do it.
  
  
 2009-02-11 
 
 __
 zuowenping 
 
 __
 发件人： jitendraj...@emerson.com 
 发送时间： 2009-02-11  16:12:50 
 收件人： zuowenp...@dali-tech.com;
 davinci-linux-open-source@linux.davincidsp.com 
 抄送： 
 主题： RE: nand_programmer check all nand flash blocks error 
 
 Hi Duke Zuo,
 
 We are also struggling with similar issue since few weeks. We have
 done some investigation that might help you.
 
  
 
 1. What NAND chip you are using? 
 
 2. What is the page size? As per TI, RBL does not support NAND having
 4096 page size 
 
 3. Are you able to do UART boot? 
 
 4. Have you modified anything in “NAND_Programmer.pjt” source code? If
 yes, what are those? 
 
 5. It is surprising to see your changes related to ALE/CMD address, we
 are not required to do so.
 
  
 
 Regards,
 
 Jitendra
 
  
 
  
 
 
 
 From: davinci-linux-open-source-boun...@linux.davincidsp.com
 [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
 Behalf Of zuowenping
 
 Sent: Wednesday, February 11, 2009 12:55 PM
 
 To: davinci-linux-open-source
 
 Subject: nand_programmer check all nand flash blocks error
 
  
 
 dear all:
 
 I use a new nand flash for dm355 in my new borad,first i used
 Micron 1G nand flash, the address have been modify:
 
 #define NAND_ALE_ADDR ((volatile Uint8*)0x0204)  //from
 0x0208
 
 #define NAND_CMD_ADDR ((volatile Uint8*)0x0208)  //from
 0x0210
 
 if i use the old address, the Manufacture id and device id is
 always 0 when read it.and the hardware told me to modify the address!
 but when I run the programmer by jtag,the result is:
 
 Started Nand programming
 
  Manufacture ID 2c
 
  device ID d3
 
  find the NAND device in the table!
 
 NANDInit() Successful
 
 Enter the UBL File Name
 
 D:\dvsdk_1_30_00_40\dvsdk_1_30_00_40\PSP_01_20_00_014\bin\dm355
 \ublDM355-nand.bin
 
  Block number 0 is a BAD BLOCKBlock 0 is a bad block
 
  Block number 1 is a BAD BLOCKBlock 1 is a bad block
 
  Block number 2 is a BAD BLOCKBlock 2 is a bad block
 
  Block number 3 is a BAD BLOCKBlock 3 is a bad block
 
  Block number 4 is a BAD BLOCKBlock 4 is a bad block
 
  Block number 5 is a BAD BLOCKBlock 5 is a bad block
 
  Block number 6 is a BAD BLOCKBlock 6 is a bad block
 
  Block number 7 is a BAD BLOCKBlock 7 is a bad block
 
  Block number 8 is a BAD BLOCKBlock 8 is a bad block
 
  Block number 9 is a BAD BLOCKBlock 9 is a bad block
 
  Block number 10 is a BAD BLOCKBlock 10 is a bad block
 
  Block number 11 is a BAD BLOCKBlock 11 is a bad block
 
  Block number 12 is a BAD BLOCKBlock 12 is a bad block
 
  Block number 13 is a BAD BLOCKBlock 13 is a bad block
 
  Block number 14 is a BAD BLOCKBlock 14 is a bad block
 
  Block number 15 is a BAD BLOCKBlock 15 is a bad block
 
  Block number 16 is a BAD BLOCKBlock 16 is a bad block
 
  Block number 17 is a BAD BLOCKBlock 17 is a bad block
 
  Block number 18 is a BAD BLOCKBlock 18 is a bad block
 
  Block number 19 is a BAD BLOCKBlock 19 is a bad block
 
  Block number 20 is a BAD BLOCKBlock 20 is a bad block
 
  .
 
  It seemd all block is bad!!
 
  When i skip the block checking(just return E_PASS
 in NANDCheckBadBlock() function ),it can run ok,the ubl and uboot
 seems burning ok,but when i reboot the board,it cann't boot!!
 
  I have contact to the supporter by ti,they told me the RBL(rom
 boot loader) can't support 128 pages of a block,so i changed a nand
 flash type HY27UG088G whick 64 pages of a block,it
 seem the same result! 
 
  any one can help me?thanks a lot!! 
 
 2009-02-11 
 
 
 
 duke zuo
 
 da-li tech in hangzhou 

Re: RE: RE: nand_programmer check all nand flash blocks error

[zuowenping]

thanks all! problem have been resolved,the hardware engineer have reversed the 
nand flash ale and cle line,so the address have to been changed! and in 
fact the command address shouldn't been change!


2009-02-11 



zuowenping 



发件人： jitendraj...@emerson.com 
发送时间： 2009-02-11  17:19:08 
收件人： zuowenp...@dali-tech.com; davinci-linux-open-source@linux.davincidsp.com 
抄送： 
主题： RE: RE: nand_programmer check all nand flash blocks error 
 
Hi Zuo,
Could you pls elaborate more on “change nand flash type to HY27UG088”?
Are you physically changing the NAND flash or doing software changes?
 
Also when you skip the NANDCheckBadBlock () function, you said the ubl and 
uboot seems burning ok, but when you reboot the board, it can’t boot!!
So can you read 32 bits of ARM internal memory (0x7ffc-0x8000) via JTAG and let 
us know what you are getting.
 
Regards,
Jitendra



From: zuowenping [mailto:zuowenp...@dali-tech.com] 
Sent: Wednesday, February 11, 2009 2:06 PM
To: Jain, Jitendra [PROTOOL/RTC/IN]; davinci-linux-open-sou...@linux.
Subject: Re: RE: nand_programmer check all nand flash blocks error
 
1:first i use the nand flash type is MT29F8G08MAAWC,if i cann't modify the 
address,the  Manufacture  and device id is always 0,and the hardware engineer 
told me to modify it,then the id can be identify ok.when i change nand flash 
type to HY27UG088 ,the same result it is!
2:the micron flash page size is 2048+64,and the HY27UG088 is also size.
3:we can do uart boot and i have test it ok,but i have xds560 emluator,it can 
translate data easy!
4:if i use the MT29F8G08M,i have to add {0xD3, 128,  2048+64,23, 5},  
/* Micron  MT29F8G08AAA */ //add by duke 2009.2.9 
item in the const NAND_DEVICE_INFO   gNandDevInfo[] 
5:I am surprising too,but the hardware engineer ask me to do it.
 
 
2009-02-11 



zuowenping 



发件人： jitendraj...@emerson.com 
发送时间： 2009-02-11  16:12:50 
收件人： zuowenp...@dali-tech.com; davinci-linux-open-source@linux.davincidsp.com 
抄送： 
主题： RE: nand_programmer check all nand flash blocks error 
Hi Duke Zuo,
We are also struggling with similar issue since few weeks. We have done some 
investigation that might help you.
 
1. What NAND chip you are using? 
2. What is the page size? As per TI, RBL does not support NAND having 4096 page 
size 
3. Are you able to do UART boot? 
4. Have you modified anything in “NAND_Programmer.pjt” source code? If yes, 
what are those? 
5. It is surprising to see your changes related to ALE/CMD address, we are not 
required to do so.
 
Regards,
Jitendra
 
 

From: davinci-linux-open-source-boun...@linux.davincidsp.com 
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of 
zuowenping
Sent: Wednesday, February 11, 2009 12:55 PM
To: davinci-linux-open-source
Subject: nand_programmer check all nand flash blocks error
 
dear all:
I use a new nand flash for dm355 in my new borad,first i used Micron 1G 
nand flash, the address have been modify:
#define NAND_ALE_ADDR ((volatile Uint8*)0x0204)  //from 0x0208
#define NAND_CMD_ADDR ((volatile Uint8*)0x0208)  //from 0x0210
if i use the old address, the Manufacture id and device id is always 0 when 
read it.and the hardware told me to modify the address!but when I run the 
programmer by jtag,the result is:
Started Nand programming
 Manufacture ID 2c
 device ID d3
 find the NAND device in the table!
NANDInit() Successful
Enter the UBL File Name

D:\dvsdk_1_30_00_40\dvsdk_1_30_00_40\PSP_01_20_00_014\bin\dm355\ublDM355-nand.bin
 Block number 0 is a BAD BLOCKBlock 0 is a bad block
 Block number 1 is a BAD BLOCKBlock 1 is a bad block
 Block number 2 is a BAD BLOCKBlock 2 is a bad block
 Block number 3 is a BAD BLOCKBlock 3 is a bad block
 Block number 4 is a BAD BLOCKBlock 4 is a bad block
 Block number 5 is a BAD BLOCKBlock 5 is a bad block
 Block number 6 is a BAD BLOCKBlock 6 is a bad block
 Block number 7 is a BAD BLOCKBlock 7 is a bad block
 Block number 8 is a BAD BLOCKBlock 8 is a bad block
 Block number 9 is a BAD BLOCKBlock 9 is a bad block
 Block number 10 is a BAD BLOCKBlock 10 is a bad block
 Block number 11 is a BAD BLOCKBlock 11 is a bad block
 Block number 12 is a BAD BLOCKBlock 12 is a bad block
 Block number 13 is a BAD BLOCKBlock 13 is a bad block
 Block number 14 is a BAD BLOCKBlock 14 is a bad block
 Block number 15 is a BAD BLOCKBlock 15 is a bad block
 Block number 16 is a BAD BLOCKBlock 16 is a bad block
 Block number 17 is a BAD BLOCKBlock 17 is a bad block
 Block number 18 is a BAD BLOCKBlock 18 is a bad block
 Block number 19 is a BAD BLOCKBlock 19 is a bad block
 Block number 20 is a BAD BLOCKBlock 20 is a bad block
 .
 It seemd all block is bad!!
 When i skip the block checking(just return E_PASS in NANDCheckBadBlock() 
function 

RE: [PATCH 2/2] ARM: DaVinci: EMAC: Add PHY mask info to platform data

[Steve Chen]

On Wed, 2009-02-11 at 11:20 +0530, Subrahmanya, Chaithrika wrote:
  On Tue, 2009-02-10 at 18:09 +0530, chaithr...@ti.com wrote:
   From: Chaithrika U S chaithr...@ti.com
  
   @@ -2443,34 +2454,43 @@ static int emac_dev_open(struct net_device
  *ndev)
  
  /* find the first phy */
  priv-phydev = NULL;
   - for (phy_addr = 0; phy_addr  PHY_MAX_ADDR; phy_addr++) {
   - if (priv-mii_bus-phy_map[phy_addr]) {
   - priv-phydev = priv-mii_bus-
  phy_map[phy_addr];
   - break;
   + if (priv-phy_mask) {
   + for (phy_addr = 0; phy_addr  PHY_MAX_ADDR; phy_addr++)
  {
   + if (priv-mii_bus-phy_map[phy_addr]) {
   + priv-phydev = priv-mii_bus-
  phy_map[phy_addr];
   + break;
   + }
  
  Address 0, I believe is broadcast PHY.  Would this cause problem for
  DM644x EVM with  LX971?
  
  What happens if we have multiple phys?  For example wired and wireless
  or even optical interface?
  
  Also, if we can scan for PHYs, do we still need to hard code the
  phy_mask in platform data?  Can the phy_mask be determined dynamically
  based on the scan?
 
 If there are multiple PHYs the first phy found will be connected.
 If all the phy address have to be scanned, then the mask should be set to 
 0x.
I'm trying to get at is that if we already know the phy address(es), and
it is already in platform data.  What additional value does scan phy
address dynamically provide?  Also, the code only allows 1 phy.  To
manage multiple phys priv-phydev needs to be an array.

 
 The mask is used to make sure you only look at PHYs you care about.
 Setting the mask to 0 will not access registers of any PHY.

If this is what you are trying to do, should the code look more like

...
if ((priv-phy_mask  (0x1  phy_addr)) 
priv-mii_bus-phy_map[phy_addr])
priv-phydev = priv-mii_bus-phy_map[phy_adr];
...

Regards,

Steve


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH 2/2] ARM: DaVinci: EMAC: Add PHY mask info to platform data

[Steve Chen]

On Wed, 2009-02-11 at 11:34 +0530, Subrahmanya, Chaithrika wrote:
  
  On Tuesday 10 February 2009, chaithr...@ti.com wrote:
#define DAVINCI_I2C_BASE0x01C21000
   +#define DAVINCI_EVM_PHY_MASK   0x2
#define DAVINCI_EMAC_BASE  0x01C8
#define DAVINCI_EMAC_CNTRL_OFFSET  0x
#define DAVINCI_EMAC_CNTRL_MOD_OFFSET  0x1000
   @@ -270,6 +271,7 @@ static struct emac_platform_data emac_pdata = {
   .ctrl_ram_offset= DAVINCI_EMAC_CNTRL_RAM_OFFSET,
   .mdio_reg_offset= DAVINCI_EMAC_MDIO_OFFSET,
   .ctrl_ram_size  = DAVINCI_EMAC_CNTRL_RAM_SIZE,
   +   .phy_mask   = DAVINCI_EVM_PHY_MASK,
  
  Surely the PHY address mask should be board-specific,
  if it's got to be hard-wired.
  
  But ... is it not practical to dynamically probe it?
  That's what most Ethernet drivers do.  The MDIO module
  continuously polls all 32 MDIO addresses in order to
  enumerate the PHY devices in the system ... so when
  that polling returns a single PHY there should be no
  question about which one to use.
  
 
 The PHY mask was put in place originally to take care of the case where PHYs 
 connected to multiple instances of EMAC are serviced by single MDIO module. 
 It helped differentiate which PHY belongs to which MAC. However, we don't 
 have 
 that case on DaVinci (yet). I don't think the driver is fully there to take 
 care of that 
 case, but we wanted to retain this support just in case.

Will there be a case where multiple phys hang off of a single MAC?

 
 Also, it helps tell the driver to not care about any connected PHY (by 
 setting the 
 mask to 0). The OMAP-L137 EVM has a switch connected to the MAC instead 
 of a PHY. In that case, most likely, mask value of zero will be used.

We should be able to read the device id and make decisions based on
device id.  Will that be preferred over hard coded values?

 
  
  
/* TODO: This should come from platform data */

I guess this comment can now be removed :)

   -#define EMAC_EVM_PHY_MASK  (0x2)
#define EMAC_EVM_MLINK_MASK(0)
#define EMAC_EVM_BUS_FREQUENCY (7650) /* PLL/6 i.e 76.5
  MHz */
#define EMAC_EVM_MDIO_FREQUENCY(220) /* PHY bus
  frequency */
  
  EVM_MLINK_MASK is not used in the driver.
  Ditto EVM_BUS_FREQUENCY.  Might as well
  just delete them in this patch.
  
  And I suspect that EVM_MDIO_FREQUENCY should
  be derived from the EMAC clock ...
 
 OK, will do the changes and submit a patch.
 
 Thanks,
 Chaithrika
 
  
  - Dave
  ___
 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: [PATCH 9/9] musb_gadget_ep0: fix unhandled IRQ

[Sergei Shtylyov]

Hello, I wrote:

The EP0 code routinely ignores interrupt at end of the data phase 
because of
musb_g_ep0_giveback() resetting the state machine to idle, waiting 
for SETUP

phase prematurely.



Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com



---
This fixes most of the unhandled gadget interrupts that 
generic_interrupt() and
davinci_interrupt() have been hiding from user by faking their 
result and only

emitting 5th level debug message (for what is clearly an error).


   And of course it turrned out to be only yhe tip of an iceberg. It 
uncovered another race happening when the last IN packet is sent and 
CSR.DataEnd bit is set along with it: there supposed to be *two* 
interrupts after that -- they seem to often be coalsesced into a 
single one (when using Linux host)


  Perhaps it's the status completion and the SETUP packet reception 
interrupts that get coalesced...


  Er, no... those should be more spaced in time because of 8-byte SETUP 
packet that gets received in between them.


   So, I'm goind to recast this patch, adding more fixes -- if there's 


s/goind/going/


no objections...


   Perhaps the simplest thing to do would be to return IRQ_HANDLED 
from the idle, waiting for SETUP phase regardess of RxPktRdy...


  It's not just simplest, it now seems the only correct thing to do. 


  I'm considering addition of another (tryly idle) phase because the 
stage after the status phase completion interrupt and before the 
RxPktRdy interrupt was clearly missed.


However, falling thru from the status in/out state right into the idle 
state seems of dubios value. I always see (at least) two distinct 
interrupts.


WBR, Sergei



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: DaVinci git updated to v2.6.29-rc4, source.mvista.com repo going away

[David Brownell]

Appended is a patch for one USB goof.  Also, the MMC driver
is ... quite an old version.  NAND isn't current either.

- Dave

= CUT HERE
From: David Brownell dbrown...@users.sourceforge.net

Restore a change that was wrongly dropped from mainline.

Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
 arch/arm/mach-davinci/usb.c |   23 ---
 1 file changed, 23 deletions(-)

--- a/arch/arm/mach-davinci/usb.c
+++ b/arch/arm/mach-davinci/usb.c
@@ -79,29 +79,6 @@ static struct platform_device usb_dev = 
.num_resources  = ARRAY_SIZE(usb_resources),
 };
 
-#ifdef CONFIG_USB_MUSB_OTG
-
-static struct otg_transceiver *xceiv;
-
-struct otg_transceiver *otg_get_transceiver(void)
-{
-   if (xceiv)
-   get_device(xceiv-dev);
-   return xceiv;
-}
-EXPORT_SYMBOL(otg_get_transceiver);
-
-int otg_set_transceiver(struct otg_transceiver *x)
-{
-   if (xceiv  x)
-   return -EBUSY;
-   xceiv = x;
-   return 0;
-}
-EXPORT_SYMBOL(otg_set_transceiver);
-
-#endif
-
 void __init setup_usb(unsigned mA, unsigned potpgt_msec)
 {
usb_data.power = mA / 2;


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Dsplink.dsp?

[David Chan]

Hi guys,

Don't guess anymore. I've built my own codec package tree and codec  
server tree. DDR is not the problem. From DSPLINK1.40. DDR2 to is used  
to take the place of DDR. Just rename the section DDR to DDR2. and  
modify the correspond to DDR in the .cfg file. It will be compiled  
without any problem. But When the server run your Linux system will be  
crashed. I've check with TI, the problem should be from the codec  
himself. Codec is not compatible to Xdais 6.20 or later, hence  
imcompatible to dsplink1.6.  They send me a mail, that they've send me  
the new codec. But problem now is I can't track my package with Fedex.

Wish I can got them soon.
On Feb 11, 2009, at 9:15 PM, Griffis, Brad wrote:

I've run into similar issues in the past.  In my case the error  
originated in the tcf file for the DSP.  There seems to be a little  
bit of inconsistency in the naming of the external memory.  I have  
seen some processors where it's called DDR and other processors  
where it's called DDR2.



-Original Message-
From: Ryan Talbot [mailto:rtal...@vtti.vt.edu]
Sent: Wednesday, February 11, 2009 3:57 AM
To: David Chan
Cc: Griffis, Brad; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Dsplink.dsp?

Hey guys,

I'm now getting a linker error while building the server.  It says  
that
_DDR2 is an undefined symbol, coming from dsplink.lib.  I guess  
this is

because I am now using DSPLink 1.60 instead of 1.30, but I can't find
any information on this _DDR2 symbol.  Does anybody know what it  
means

or what it should be?

I also could not find the BIOSUtils package anywhere as a standalone
download.  I ended up creating a symbolic 'bios' link that resides in
codec_engine_2_21/packages/ti that points to
codec_engine_2_21/cetools/packages/ti/bios, because otherwise the
compilation would fail saying that it couldn't find the package
ti.bios.utils.

You guys have been a great help, thanks!
Ryan


-Original Message-
From: David Chan [mailto:blacksword.da...@gmail.com]
Sent: Tuesday, February 10, 2009 9:04 AM
To: Ryan Talbot
Cc: Griffis, Brad; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Dsplink.dsp?

Ryan,

It's seems that you are not using the DVSDK2.0EA edition. I
think that you will meet another roadblock as I have meet.

If the codec is not developed by your own team, you will find
that the Codec is not compatible the dsplink 1.50 or later.
(Video_copy can run, but the codec server from current codecs
will crashed the kernel! This is why my personal release of
CE2.21 based on my toolchain is delayed)

Just got the mail from TI, that new codecs are Fedexed to me.
But until now, I don't know where are them. Trying tracking them  
now!


The best now seems to be dsplink1.4 with mv50 (or my
toolchain) and new kernel .

David
On Feb 10, 2009, at 2:08 PM, Ryan Talbot wrote:


Thanks, Brad, that seems to have cleared that roadblock.  I hadn't
noticed that difference between the two releases...

downloading each

component separately really is proving to be a pain.

David, thanks again for your input earlier; I was in the process of
implementing it when Brad's solution showed up in my inbox

and did the

trick.

Ryan


-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
] On Behalf Of Griffis, Brad
Sent: Monday, February 09, 2009 10:06 PM
To: Ryan Talbot; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Dsplink.dsp?

This path is likely incorrect:

/home/rtalbot/dvevm_2_21/dsplink_1_60/packages

You need to do one of the following to fix it:

1)  Root through the various makefiles to figure out where they
define XDCPATH and delete the extra packages they are

appending to

the dsplink path.

- OR -

2)  Add a packages folder in between the dsplink_1_60
folder and the dsplink folder.  (This is probably the
quickest/easiest.)

I think this all came about because there is a CONVENTION at TI to
put all the RTSC packages of a product into a directory called
packages.  DSPLink does not follow this convention and the DVSDK
tried to force the convention upon DSPLink.  So in the version of
dsplink that is delivered with the DVSDK they created that extra
directory called packages so it would follow the same

convention as

everything else.  It makes everything look uniform, but it

can be a

real pain in the rear if you try to use a freshly

downloaded version

of dsplink.

Brad


-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com


[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On

Behalf Of Ryan Talbot
Sent: Saturday, February 07, 2009 2:01 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Dsplink.dsp?

Hi folks,

I feel that I must have missed something simple, but I

can't for the

life of me figure out what it was.  I followed the

directions to build

the DSP side of DSPLink that are outlined here:

RE: Gstreamer:video OK audio problem

[Griffis, Brad]

I don't know anything about gstreamer in order to help you solve your issue, 
but I do know that there is another gstreamer project that is being actively 
worked right now:

https://omapzoom.org/gf/project/gstreamer_ti/wiki/

Perhaps you will have better luck with it.  It's running on all OMAP and 
Davinci platforms so there seems to be good progress there.

Brad

 -Original Message-
 From: davinci-linux-open-source-
 bounces+bgriffis=ti@linux.davincidsp.com [mailto:davinci-linux-open-
 source-bounces+bgriffis=ti@linux.davincidsp.com] On Behalf Of zhenfeng
 ren
 Sent: Wednesday, February 11, 2009 2:40 AM
 To: Davinci-linux-open-source@linux.davincidsp.com
 Subject: Gstreamer:video OK audio problem
 
 hello,everyone:
 
 I download gstreamer from:
   http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100
 
 When I run test_AVI.sh, video is OK.  I have tested some AVI
 files.Some files only first few seconds audio is OK(about 2 second ?),
 then no sound. Some files there is no sound at all.
 Anyone give me some suggestion?
 
 --
 Thanks,
 Zhenfeng Ren
 
 ___
 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: FYI: upstream-cleanup branch

[Kumar, Purushotam]

David Brownell wrote: 
 Oh, and one more issue likely to appear in a public review:
 there are a couple un-bounded loops, which should get terminated.
 Appended is a patch I've been running with, which at least gets
 rid of the system hangs aspect of such loop (even if there's
 no particularly good cleanup).
 
 I hope you're planning to send this up for review soon, so that
 it will be in the 2.6.30 merge queue when the merge window opens...
   host-bus_mode = ios-bus_mode;
   if (ios-power_mode == MMC_POWER_UP) {
 + unsigned long timeout = jiffies + msecs_to_jiffies(50);
 + bool lose = true;
 +
   /* Send clock cycles, poll completion */
   writel(0, host-base + DAVINCI_MMCARGHL);
   writel(MMCCMD_INITCK, host-base + DAVINCI_MMCCMD);
 - while (!(readl(host-base + DAVINCI_MMCST0)  MMCST0_RSPDNE))
 + while (time_before(jiffies, timeout)) {
 + u32 tmp = readl(host-base + DAVINCI_MMCST0);
 +
 + if (tmp  MMCST0_RSPDNE) {
 + lose = false;
 + break;
 + }
   cpu_relax();
 + }
 + if (lose)
 + dev_warn(mmc_dev(host-mmc), powerup timeout\n);
   }

I agree to this and we should incorporate it. It will help us to get out of 
while loop.

 @@ -907,6 +919,7 @@ static inline int handle_core_command(
   int end_transfer = 0;
   unsigned int qstatus = status;
   struct mmc_data *data = host-data;
 + unsigned count = 0;
 
   /* handle FIFO first when using PIO for data */
   while (host-bytes_left  (status  (MMCST0_DXRDY | MMCST0_DRRDY))) {
 @@ -914,7 +927,12 @@ static inline int handle_core_command(
   status = readl(host-base + DAVINCI_MMCST0);
   if (!status)
   break;
 +
   qstatus |= status;
 + if (count++  40) {
 + dev_dbg(mmc_dev(host-mmc), PIO timeout\n);
 + break;
 + }
   }
 
   if (qstatus  MMCST0_DATDNE) {

I think it has potential bug. DAVINCI_MMCST0 register has been read (assume 
that either MMCST0_DXRDY or MMCST0_DRRDY was also set) and at same time it will 
break if count has reached 41. There will be no write to FIFO and so 
MMCST0_DXRDY/MMCST0_DRRDY will not be set again and so no next interrupt which 
could cause hang. In order to fix this bug, we need to check count value before 
DAVINCI_MMCST0 register read. But, I feel we should not add any PIO timeout 
here. I checked on EVM and count has never increased more than 1 for high speed 
card.

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Goodbye and Thanks - I'm off to Tokyo. (Anyone hiring?)

[Jon Povey]

Just a note to say thanks to all the people on this list who have helped
me out directly or indirectly, our DM355-based product is now shipping
and I'm leaving the company to seek my fortune in Tokyo.

I don't have anything lined up there, and being a global recession is a
suboptimal time to go, but now is the time for me to give it a go.

So, please excuse the self-advertisment, but if anyone is looking for an
embedded systems software engineer over there, do get in touch. After
the 20th I can be contacted as jon at leetfighter dot com.

So long, and best of luck with the GIT kernel work and your individual
projects.

Cheers,

-- 
Jon Povey, Design Engineer
jon.po...@racelogic.co.uk | +44(0)1280 825983 

 
Racelogic is a limited company registered in England. Registered number 2743719 
. 
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, 
MK18 1TB .
The information contained in this electronic mail transmission is intended by 
Racelogic Ltd for the use of the named individual or entity to which it is 
directed and may contain information that is confidential or privileged. If you 
have received this electronic mail transmission in error, please delete it from 
your system without copying or forwarding it, and notify the sender of the 
error by reply email so that the sender's address records can be corrected. The 
views expressed by the sender of this communication do not necessarily 
represent those of Racelogic Ltd. Please note that Racelogic reserves the right 
to monitor e-mail communications passing through its network

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Error build codec servers in DM6446: incompatible use of taget

[Jon Arróspide]

Hello all,

I'm trying to build a codec server in DM6446. However, even if I try to 
build an example server (video_copy) I'm getting the following error:


js: /opt/dvevm_1_10/xdctools_1_21/packages/xdc/cfg/cfg.js, line 143: 
exception from uncaught _javascript_ throw: *Error: incompatible use of 
the target 'ti.targets.C64P'*, imported version [], ti.targets.rts6000 
was built using version [1,0,5.2,0,4], ti.sdo.ce.trace was built using 
version [1,0,6.0,3], ti.sdo.ce.osal.alg was built using version 
[1,0,6.0,3], ti.bios.utils was built using version [1,0,6.0,3], ti.bios 
was built using version [1,0,6.0,3], ti.rtdx was built using version 
[1,0,6.0,3], ti.sdo.ce.osal was built using version [1,0,6.0,3], 
ti.sdo.fc.dskt2 was built using version [1,0,6.0,3], ti.sdo.fc.dman3 was 
built using version [1,0,6.0,3], ti.sdo.fc.acpy3 was built using version 
[1,0,6.0,3], ti.sdo.ce.bioslog was built using version [1,0,6.0,3], 
ti.sdo.ce.node was built using version [1,0,6.0,3], ti.sdo.ce was built 
using version [1,0,6.0,3], ti.sdo.ce.video was built using version 
[1,0,6.0,3], codecs.viddec_copy was built using version [1,0,6.0,3], 
codecs.videnc_copy was built using version [1,0,6.0,3]

gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Error 1
gmake: *** Deleting file `package/cfg/video_copy_x64Pcfg_c.c'
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file 
`package/cfg/video_copy_x64Pcfg.cmd'
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file 
`package/cfg/video_copy_x64Pcfg.s62'

make: *** [all] Error 2

Has anybody encountered this problem? Do I need to download some 
upgraded (or downgraded) version of a library/file?

Thank you in advance,

Jon
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Davinci-linux-open-source Digest, Vol 38, Issue 55

[David Chan]

Hi, Jon

I think that you have a wrong cgtools used. please use cg6x_6_0_15 or  
later.


David Chan (also know as BlackSword.David)

On Feb 11, 2009, at 11:32 PM, davinci-linux-open-source-requ...@linux.davincidsp.com 
 wrote:



Date: Wed, 11 Feb 2009 16:27:37 +0100
From: Jon Arr?spide j...@gti.ssr.upm.es
Subject: Error build codec servers in DM6446: incompatible use of
taget
To: davinci-linux-open-source@linux.davincidsp.com
Message-ID: 4992ee69.8080...@gti.ssr.upm.es
Content-Type: text/plain; charset=iso-8859-1

Hello all,

I'm trying to build a codec server in DM6446. However, even if I try  
to

build an example server (video_copy) I'm getting the following error:

js: /opt/dvevm_1_10/xdctools_1_21/packages/xdc/cfg/cfg.js, line 143:
exception from uncaught _javascript_ throw: *Error: incompatible use  
of

the target 'ti.targets.C64P'*, imported version [], ti.targets.rts6000
was built using version [1,0,5.2,0,4], ti.sdo.ce.trace was built using
version [1,0,6.0,3], ti.sdo.ce.osal.alg was built using version
[1,0,6.0,3], ti.bios.utils was built using version [1,0,6.0,3],  
ti.bios

was built using version [1,0,6.0,3], ti.rtdx was built using version
[1,0,6.0,3], ti.sdo.ce.osal was built using version [1,0,6.0,3],
ti.sdo.fc.dskt2 was built using version [1,0,6.0,3], ti.sdo.fc.dman3  
was
built using version [1,0,6.0,3], ti.sdo.fc.acpy3 was built using  
version

[1,0,6.0,3], ti.sdo.ce.bioslog was built using version [1,0,6.0,3],
ti.sdo.ce.node was built using version [1,0,6.0,3], ti.sdo.ce was  
built

using version [1,0,6.0,3], ti.sdo.ce.video was built using version
[1,0,6.0,3], codecs.viddec_copy was built using version [1,0,6.0,3],
codecs.videnc_copy was built using version [1,0,6.0,3]
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Error 1
gmake: *** Deleting file `package/cfg/video_copy_x64Pcfg_c.c'
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file
`package/cfg/video_copy_x64Pcfg.cmd'
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file
`package/cfg/video_copy_x64Pcfg.s62'
make: *** [all] Error 2

Has anybody encountered this problem? Do I need to download some
upgraded (or downgraded) version of a library/file?
Thank you in advance,

Jon


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Davinci-linux-open-source Digest, Vol 38, Issue 55

[David Chan]

Brad,

The omapzone may need dvsdk2.0 ea.

David Chan
On Feb 11, 2009, at 11:32 PM, davinci-linux-open-source-requ...@linux.davincidsp.com 
 wrote:



Message: 2
Date: Wed, 11 Feb 2009 07:34:29 -0600
From: Griffis, Brad bgrif...@ti.com
Subject: RE: Gstreamer:video OK audio problem
To: zhenfeng ren 1985re...@gmail.com,
Davinci-linux-open-source@linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Message-ID:
f8c55f6a02e92d48bddfc6048552c6f120455...@dlee03.ent.ti.com
Content-Type: text/plain; charset=us-ascii

I don't know anything about gstreamer in order to help you solve  
your issue, but I do know that there is another gstreamer project  
that is being actively worked right now:


https://omapzoom.org/gf/project/gstreamer_ti/wiki/

Perhaps you will have better luck with it.  It's running on all OMAP  
and Davinci platforms so there seems to be good progress there.


Brad


-Original Message-
From: davinci-linux-open-source-
bounces+bgriffis=ti@linux.davincidsp.com [mailto:davinci-linux-open-
source-bounces+bgriffis=ti@linux.davincidsp.com] On Behalf Of  
zhenfeng

ren
Sent: Wednesday, February 11, 2009 2:40 AM
To: Davinci-linux-open-source@linux.davincidsp.com
Subject: Gstreamer:video OK audio problem

hello,everyone:

I download gstreamer from:
 http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100

When I run test_AVI.sh, video is OK.  I have tested some AVI
files.Some files only first few seconds audio is OK(about 2  
second ?),

then no sound. Some files there is no sound at all.
Anyone give me some suggestion?

--
Thanks,
Zhenfeng Ren

___
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: [patch davinci-git 2/3] NAND: Fix raw reads with ECC syndrome layouts

[Nori, Sekhar]

From: David Brownell
Sent: Tuesday, February 10, 2009 4:01 AM

 On Monday 09 February 2009, Narnakaje, Snehaprabha wrote:

   The syndrome based page read/write routines store ECC, and possibly
   other OOB data, right after each chunk of ECC'd data.  With ECC
   chunk size of 512 bytes and a large page (2KB) NAND, the layout is:
  
 data-0 OOB-0 data-1 OOB-1 data-2 OOB-2 data-3 OOB-3 OOB-leftover
 
  Shouldn't this be data-0 data-1 data-2 data-3 OOB-0 OOB-1 OOB-2 OOB-3?

 Not for NAND_ECC_HW_SYNDROME; have a look at how nand_base.c
 handles that.  In particular, nand_write_oob_syndrome() and
 its read-side sibling.  If it were NAND_ECC_HW -- yes.

 A key difference between them seems to be that ECC_HW_SYNDROME
 assumes that the ECC data (part of OOB-x) needs to be written
 after each ecc.bytes of data is written ... its non-syndrome
 cousin nand_write_page_hwecc() assumes that the ECC data can be
 collected and then written at the end (in the spare area).

 Flipping that around:  ECC_HW_SYNDROME presumes that the ECC
 computations on *read* rely on engine state which needs to be
 used after each ecc.bytes of data ... but ECC_HW presumes its
 state can be saved and then used later.

 Can the DaVinci 4-bit ECC state be saved/restored?  That is,
 can the NAND4BITECCx registers be read after every 512 bytes
 (so there are 40 bytes of saved ECC), then (in four chunks)
 written, so the NAND4BITECCLOAD register can be used to fix
 any errors late ... after several intervening data blocks
 have been read, and ther ECCx state saved?  Docs don't say;
 but they strongly imply not.


I don't think hardware supports saving the ECC state. The boot ROM code
in DA830 device assumes the standard layout of data-0 data-1 oob-0 oob-1
while supporting 4-bit ECC. DM355 silicon errata identifies the current
layout used by boot ROM as not recommended. I think this is planned to be
fixed in future silicon revs.

While I have not seen the OMAP-L1 ROM code, I think the standard layout
is being achieved there by reading the complete OOB area before starting
the read. Afterward, the read ECC bytes are being fed into the syndrome
calculator along with each 512 byte data read. Similarly, on write, the
ECC bytes can be cached locally before being written to spare area at once.

I found this algorithm being used by DM355 flash utils here:
http://sourceforge.net/project/showfiles.php?group_id=233754package_id=283791release_id=630108
 (See Common/drivers/src/nand.c)

Of course, the code in nand_base.c does not accommodate this. May be
overriding the *_syndrome()functions for davinci is the only near term
solution?

Thanks,
Sekhar


  We used to have the data-0 OOB-0 ... layout in the Montavista based
  LSP releases. This layout can cause to place real data in the spare
  area and erase NAND manufacturer's meta-data -- bad block information.

 Right.  Inherent in the NAND_ECC_HW_SYNDROME code in mainline too.

 I've checked around a bit, and it seems that the HW_SYNDROME mode
 isn't much used (yet?) where ecc.steps is more than one.

 The $SUBJECT patch will be, I expect, only the first of several.
 And that's not even considering the issue of whether the ecc.prepad
 data (6 bytes OOB) is covered by the ECC ... there seems to be code
 assuming that OOB data is not protected by ECC.  (So it's writable
 at any time.)


  The standard layout should be 2048 bytes data + 64 bytes OOB. 2048 bytes
  of data should still be read in 512 byte chunks.

 That's for the non-syndrome cases only; or maybe syndromes
 that cover entire pages (2K, 4K, etc).

 (And I expect you're using 2K pages as I am, just as the most
 common current example ... the code shouldn't disallow 4K.)


  Given that we have the boards with uboot and other Bootloader components
  loaded with the old legacy layout, we may still have to support both the
 layouts.
 
  BTW, I am actually working on the support for standard layout!

 Good!  I'd expect the current 1-bit ECC code would work just
 fine for that; does it?  And making the 4-bit mode fit into
 that model will surely be a *lot* less hassle -- in terms of
 patching NAND core code -- than using the HW_SYNDROME paths.
 (More in terms of bootloader updates though.)

 On the other hand, I'd sort of hope that the first patch I
 sent would work OK for small block flash.  Though it might
 shake out assumptions about the nonprotection of OOB data.

 You can think of patches #2 and #3 as a first pass at being
 able to support the old layout.

 - Dave


  Thanks
  Sneha
 
  
   Where OOBx is (prepad, ECC, postpad).  However, the current raw
   routines use a traditional layout -- data OOB, disregarding the
   prepad and postpad values -- so when they're used with that type of
   ECC hardware, those calls mix up the data and OOB.  Which means,
   in particular, that bad block tables won't be found on startup,
   with data corruption and related chaos ensuing.
  
   The current syndrome-based drivers in mainline all seem to use one
 

Re: DaVinci git updated to v2.6.29-rc4, source.mvista.com repo going away

[Kevin Hilman]

David Brownell davi...@pacbell.net writes:

 Appended is a patch for one USB goof.  Also, the MMC driver
 is ... quite an old version.  NAND isn't current either.

Hmm, this USB change is already in my tree.  And the NAND driver[1]
is the same for me as pre-merge, and so is MMC[2].

Maybe there were some problems pushing to the master repo, or 
the kernel.org mirrors are not sync'd?

Can you re-pull. I will pull a fresh copy from the master repo and try
to see what is happening.

Kevin


[1] $ git log --pretty=oneline drivers/mtd/nand/davinci_nand.c
314b20bd4b4535ade2373df0902553a3a321c34d clock: more clock and PLL framework 
updates
07190aa9f93b2ff107c15ef2e6c2c4a6dd266275 davinci_nand: cleanup
d776fbaa6b73aa27c0bfd73a7b8e00792013795f davinci_nand: clean up the A1CR hacks
07a05972b189dacc8025cb13687d4f362534e07d davinci_nand: chipselects, we got your 
chipselects
2acdf27b54d08e62778dd3d554cd1889e406834c davinci_nand: allow board-specific 
config
7ab1eee5804f9362460ead7f67b5295aac324017 davinci_nand: use standard badblock 
support
a0f165a207f97a9a218e57ec61ec62d290097970 nand: dm6446 mux cleanup
6bb747f303afe7ba9063e32c23537968dceb631b nand: minor ecc cleanup (mostly)
044139ea9ecd2f51cc7632932871c7824818f271 ARM: DaVinci: generalize dm644x pinmux
7b8fdcc756c4b6f01bc751adeca2fb17acab66cf davinci_nand partial ALE/CLE 
parameterization
a7856de149e106d42f22c4eb5073924d5d09147a davinci_nand separate dm355evm and 
dm6446evm specifics
d854204b680ab173c3c9eaa4f285ba66cce99e8f davinci_nand ecc (1-bit) config 
handling
6ca5e583adef5cfefd808ed77389e5de0a2cd87e davinci_nand partition config handling
247e1acf0134dae7ab4ec4e7d345063276e874b0 davinci_nand uses io{read, write}{8, 
16, 32}_rep
8e64eb496fd09a84b5ac99665a4366f5aea28138 mtd: nand: davinci: use 
platform_driver_probe()
e9a259ba8b92457dda71005e03af6516cef226ba mtd: nand: davinci: only try to fix 
mux settings on dm6446
01aa28d4799c8e551c63810913167b5cabd2e257 mtd: nand: davinci: add missing 
__devinit
c286b11f1b448276192573b3cd4e6801f5ce359d mtd: nand: convert printk to dev_dbg 
and friends
502eab9742bc47e0b3a57e695b6d864d6f7dd53b mtd: nand: introduce davinci_nand_info
14f80ce166391ba6fc418158f7fa55995f73681c mtd: nand: davinci: don't cast 
unnecessarily
3ba8d4169c044f6efe104849cfac2338fddc58fe mtd: nand: davinci: checkpatch.pl fixes
f60b03b46fa2de3d87ca2b227b6eee20b1a6b92d arch: davinci: pass emif control base 
via resource
d36d4fd0396bf9cd3b1bee5227ad6f45a5dfef89 MTD: DaVinci NAND: define base address
827ab36338c3384e1a1d854939c5a24de594a7b5 ARM: DaVinci: fixup include paths 
after asm/arch -- mach change
3272aab9d3e152ea1860d860bb241cf203319f25 ARM: DaVinci: Fix NAND compilation
a5cc88c0f7ea47790ade26f7c979a77bd0fa9bc2 ARM: DAVINCI: Add NAND driver

[2] $ git log --pretty=oneline drivers/mmc/host/davinci_mmc.c
5d0acbd9ce588c27a3c4bd66e5276a325b71f943 davinci: drop mach/board.h and move 
mmc stuff to mach/mmc.h
f9719b2d8f29e5bef46a51594d79643fff045221 MMC/SD scatterlists using EDMA linkage
9bf002cddd21211dabfad7f3859fd8141fb942dd MMC/SD code shrinkage (minor)
4f8ee6ae0227aba9af4162446a547f12bbdc2287 MMC/SD dma fault handling fixes
bd417539ba5af357b817dcad357b04e69b98ae93 MMC/SD allocates extra EDMA slots
3c8fcf7722a8edd280d1aa84f90702e84fc536a2 EDMA TC selection updates
9df2a6b81c3991a938b9c6e5fbe9d50c9f99067d EDMA renames: all remaining operations
18478af5ab8d94db50a75526ede354f664d6a6ce EDMA renames: remaining parameter RAM 
ops
b69e435db5899ea448a10af498cc1d38f510 EDMA renames: edma_start(), edma_stop()
62ef2b071b3cf7c940227e4e61dd981297c5f479 EDMA: split channel/slot resource 
management
ce31af1dc071ff94285f0351bb4d1891a187c499 EDMA renames: edma_read_slot(), 
edma_write_slot()
154cea4f78ce490e4793c0efa68d848ee25adffa mmc: only dm355 supports high speed
7029db6f94693703a4262732574aea3f4e7299ab streamline davinci_mmc transfer setup
e3bbe046b0da2f20cc81f7d238aa3d73edc1f70b remove dubious mmc dma chaining code
b09c8b5980e6a9a6d0e73e978fbe8b79810abaa0 pass more mmc_test cases
e5fa026e802319cb5c9e3a08e7149cd637452e4a simplify mmc_davinci_send_dma_request()
cb115f81d2cb79d5bc64911e74d6072acc9a4e44 shrink mmc_davinci_send_dma_request()
240a19fd831c02ae78fc5d6ff78ff137c6547b02 mmc symbol cleanup
212e119dab6b005b599e204903be8e0b376734e1 mmc cleanups, mostly DMA/scatterlists
4b833f9852a85de9152789781b47b4898dc338b9 SD/MMC high speed support
73f52410b63c02c66d25002d962d068f9dcbf942 Revert mmc: host: davinci: 
reimplement read/write fifo in C
749cc176a3ac6e631d0fe1f3a5eabb4071347e80 mmc: host: davinci: remove unused 
define
e76b00e0f4e0bd8f81f0afadb0922a0b5926c6fd mmc: host: davinci: remove 
davinci_mmc.h
eb708ac1fd19560ac970cd898d09c9bf7338e642 mmc: host: davinci: add module 
parameters
1911a00449014b65954d79d2683fee1fd4ff0f20 mmc: host: davinci: add missing 
section definitions
f0774a21d4433850f512f9f0084b4bc60e2de26d mmc: host: davinci: general cleanups
5912086e6bb12b3e36ec6c9b1fba2f7eb87daf42 mmc: host: davinci: reimplement 
read/write fifo in C

RE: Error build codec servers in DM6446: incompatible use of taget

[Ring, Chris]

Double-check that your config.bld/user.bld assignment of the C64P target's 
.rootdir is valid.

http://rtsc.eclipse.org/docs-tip/Trouble_Shooting#Configuration_fails_with_an_.22incompatible_use_of_the_target_22_error

Chris


From: davinci-linux-open-source-boun...@linux.davincidsp.com 
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of 
Jon Arróspide
Sent: Wednesday, February 11, 2009 7:28 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Error build codec servers in DM6446: incompatible use of taget

Hello all,

I'm trying to build a codec server in DM6446. However, even if I try to build 
an example server (video_copy) I'm getting the following error:

js: /opt/dvevm_1_10/xdctools_1_21/packages/xdc/cfg/cfg.js, line 143: 
exception from uncaught _javascript_ throw: Error: incompatible use of the 
target 'ti.targets.C64P', imported version [], ti.targets.rts6000 was built 
using version [1,0,5.2,0,4], ti.sdo.ce.trace was built using version 
[1,0,6.0,3], ti.sdo.ce.osal.alg was built using version [1,0,6.0,3], 
ti.bios.utils was built using version [1,0,6.0,3], ti.bios was built using 
version [1,0,6.0,3], ti.rtdx was built using version [1,0,6.0,3], 
ti.sdo.ce.osal was built using version [1,0,6.0,3], ti.sdo.fc.dskt2 was built 
using version [1,0,6.0,3], ti.sdo.fc.dman3 was built using version [1,0,6.0,3], 
ti.sdo.fc.acpy3 was built using version [1,0,6.0,3], ti.sdo.ce.bioslog was 
built using version [1,0,6.0,3], ti.sdo.ce.node was built using version 
[1,0,6.0,3], ti.sdo.ce was built using version [1,0,6.0,3], ti.sdo.ce.video was 
built using version [1,0,6.0,3], codecs.viddec_copy was built using version 
[1,0,6.0,3], codecs.videnc_copy was built using version [1,0,6.0,3]
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Error 1
gmake: *** Deleting file `package/cfg/video_copy_x64Pcfg_c.c'
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file 
`package/cfg/video_copy_x64Pcfg.cmd'
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file 
`package/cfg/video_copy_x64Pcfg.s62'
make: *** [all] Error 2

Has anybody encountered this problem? Do I need to download some upgraded (or 
downgraded) version of a library/file?
Thank you in advance,

Jon
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [patch davinci-git 2/3] NAND: Fix raw reads with ECC syndrome layouts

[Allred, Daniel]

I'm not sure I followed all the discussion here, but I can speak to what we are 
doing with the layouts, at least from the perspective of the ROM boot loader 
(though I think the intention was to use the same format from ROM through up to 
the linux MTD).  

Revision to DM355, current OMAP-L1x7, and upcoming OMAP-L1x8, upcoming DM365, 
will all use same layout.  All data will be stored in data portion of page (2K 
page device will have four 512-byte chunks, 4K page device will have eight 
512-byte chunks, etc.). All ECC info (syndrome data) will be stored in the 
OOB/spare region.  The 4-bit ECC HW requires 10 bytes of ECC data for every 
512-byte data chunk so the spare layout will consist of N (4 for 2K-page 
device, 8 for 4K-page device, etc.) 16 byte regions, one region for each 
512-byte data chunk in the main data page.  The first six bytes of this region 
are open/free.  The last 10 bytes of this region are the bytes ECC data that 
correspond to the data chunk.

When reading, all of the spare bytes data must first be read from the spare 
region and into local memory. The ECC info in these spare bytes will (must) be 
used, as appropriate, after the read of each 512-byte data chunk.

When writing, all the ECC data must be read from the HW and stored locally 
after each 512 byte chunk read.  Then that ECC data will be formatted as 
specified above and written to the OOB/spare region altogether after all data 
pages have been written.

Does that clarify anything here?

Daniel J. Allred
High Performance DSP/SoC
Catalog DSP / Emerging End Equipment

-Original Message-
From: Nori, Sekhar 
Sent: Wednesday, February 11, 2009 10:35 AM
To: David Brownell; Narnakaje, Snehaprabha
Cc: DaVinci; Allred, Daniel
Subject: RE: [patch davinci-git 2/3] NAND: Fix raw reads with ECC syndrome 
layouts


From: David Brownell
Sent: Tuesday, February 10, 2009 4:01 AM
 
 On Monday 09 February 2009, Narnakaje, Snehaprabha wrote:
 
   The syndrome based page read/write routines store ECC, and possibly
   other OOB data, right after each chunk of ECC'd data.  With ECC
   chunk size of 512 bytes and a large page (2KB) NAND, the layout is:
  
 data-0 OOB-0 data-1 OOB-1 data-2 OOB-2 data-3 OOB-3 OOB-leftover
 
  Shouldn't this be data-0 data-1 data-2 data-3 OOB-0 OOB-1 OOB-2 OOB-3?
 
 Not for NAND_ECC_HW_SYNDROME; have a look at how nand_base.c
 handles that.  In particular, nand_write_oob_syndrome() and
 its read-side sibling.  If it were NAND_ECC_HW -- yes.
 
 A key difference between them seems to be that ECC_HW_SYNDROME
 assumes that the ECC data (part of OOB-x) needs to be written
 after each ecc.bytes of data is written ... its non-syndrome
 cousin nand_write_page_hwecc() assumes that the ECC data can be
 collected and then written at the end (in the spare area).
 
 Flipping that around:  ECC_HW_SYNDROME presumes that the ECC
 computations on *read* rely on engine state which needs to be
 used after each ecc.bytes of data ... but ECC_HW presumes its
 state can be saved and then used later.
 
 Can the DaVinci 4-bit ECC state be saved/restored?  That is,
 can the NAND4BITECCx registers be read after every 512 bytes
 (so there are 40 bytes of saved ECC), then (in four chunks)
 written, so the NAND4BITECCLOAD register can be used to fix
 any errors late ... after several intervening data blocks
 have been read, and ther ECCx state saved?  Docs don't say;
 but they strongly imply not.
 

I don't think hardware supports saving the ECC state. The boot ROM code
in DA830 device assumes the standard layout of data-0 data-1 oob-0 oob-1
while supporting 4-bit ECC. DM355 silicon errata identifies the current 
layout used by boot ROM as not recommended. I think this is planned to be
fixed in future silicon revs.

While I have not seen the OMAP-L1 ROM code, I think the standard layout
is being achieved there by reading the complete OOB area before starting
the read. Afterward, the read ECC bytes are being fed into the syndrome
calculator along with each 512 byte data read. Similarly, on write, the 
ECC bytes can be cached locally before being written to spare area at once.

I found this algorithm being used by DM355 flash utils here: 
http://sourceforge.net/project/showfiles.php?group_id=233754package_id=283791release_id=630108
 (See Common/drivers/src/nand.c)

Of course, the code in nand_base.c does not accommodate this. May be 
overriding the *_syndrome()functions for davinci is the only near term
solution?

Thanks,
Sekhar

 
  We used to have the data-0 OOB-0 ... layout in the Montavista based
  LSP releases. This layout can cause to place real data in the spare
  area and erase NAND manufacturer's meta-data -- bad block information.
 
 Right.  Inherent in the NAND_ECC_HW_SYNDROME code in mainline too.
 
 I've checked around a bit, and it seems that the HW_SYNDROME mode
 isn't much used (yet?) where ecc.steps is more than one.
 
 The $SUBJECT patch will be, I expect, only the first of several.
 And that's not even considering 

RE: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG timeout issue

[Narnakaje, Snehaprabha]

Kevin,

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Wednesday, February 11, 2009 12:20 AM
 To: Narnakaje, Snehaprabha
 Cc: davinci-linux-open-source@linux.davincidsp.com
 Subject: Re: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG
 timeout issue
 
 Kevin Hilman khil...@deeprootsystems.com writes:
 
  nsnehapra...@ti.com writes:
 
  From: Sneha Narnakaje nsnehapra...@ti.com
 
  This patch fixes the NETDEV WATCHDOG timeout issue with dm9000 ethernet
  driver on DM355, while using the NFS as root filesystem.
  In the patch I have replaced the spin_lock/spin_unlock calls with
 dm9000
  specific disable/enable interrupt calls, in the dm9000 hard_start_xmit
  routine. Though it seems to be a generic issue discussed in the netdev
 list,
  this fix may not be a permanent solution, yet we can proceed with other
 drivers
  on DM355.
  I have also enabled the dm9000 option in the DM355 default
 configuration.
 
 [ ... ]
 
  --- a/drivers/net/dm9000.c
  +++ b/drivers/net/dm9000.c
  @@ -758,7 +758,8 @@ dm9000_start_xmit(struct sk_buff *skb, struct
 net_device *dev)
 if (db-tx_pkt_cnt  1)
 return 1;
 
  -  spin_lock_irqsave(db-lock, flags);
  +  /* Disable all interrupts */
  +  iow(db, DM9000_IMR, IMR_PAR);
 
  I didn't look at all the locking in this driver, but for correctness,
  I'm guessing you probably need to do the dm9000-specific disable in
  addition to the spin_lock.  That way you only add the extra interrupt
  disable, and don't change the locking.
 
 
 In otherwords, see patch below which goes on top of yours.  It keeps
 the locking intact.  Together with yours, it basically replaces the
 global IRQ disable with a dm9000 only IRQ disable.

I have tested your suggestion to keep the spin_lock/spin_unlock (and 
spin_lock_irqsave/spin_unlock_irqsave) mechanism along with my change to 
disable/re-enable dm9000 specific interrupts. Note that, disable/re-enable 
dm9000 specific interrupt sequence is required to get NFS working properly.

 
 The question still remains... what is different about the global IRQ
 disable compared to the dm9000-only IRQ disable.

After going through some testing, it looks like the issue is how we have the 
dm9000 interrupt configured on the DM355 EVM.

On DM355 EVM, we have GPIO1 configured as dm9000 interrupt line. May be on 
other boards have a dedicated dm9000 interrupt line.
If we have a dedicated interrupt (to which the disable/enable dm9000 interrupt 
is also tied), I think it is enough to use global IRQ disable/enable APIs.

 
 The other difference I can think of between this and is being replaced:
 
 If the xmit function is called with interrupts disabled, your patch
 ensures that interrupts are (re)enabled when xmit finishes.  If
 interrupts are disabled when xmit is entered, it will exit with them
 disabled as well due to the restore.  To see if that is happening, you
 might try to throw a 'WARN_ON(irqs_disabled());' in the xmit function
 in the original version (before your patch.)

There is a reason why we need to disable interrupts when we transmit dm9000 
packets. Dm9000 hardware has an internal SRAM for the transmit buffers (two 
buffers), but the hardware is capable of sending one packet at a time. While 
dm9000 hardware is in the process of sending one packet, the driver can copy 
the skb data in the second SRAM transmit buffer. In the tx interrupt completion 
routine we ask dm9000 hardware to transmit the second packet.

Thanks
Sneha

 
 Kevin
 
 commit f0a524a6bd7900556a35dcc53f3a493576ba742c
 Author: Kevin Hilman khil...@deeprootsystems.com
 Date:   Tue Feb 10 21:04:57 2009 -0800
 
 NET: dm9000: re-add spinlock, but without IRQ save/restore
 
 diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
 index 90e3fd6..20ded42 100644
 --- a/drivers/net/dm9000.c
 +++ b/drivers/net/dm9000.c
 @@ -750,7 +750,6 @@ static void dm9000_timeout(struct net_device *dev)
  static int
  dm9000_start_xmit(struct sk_buff *skb, struct net_device *dev)
  {
 - unsigned long flags;
   board_info_t *db = netdev_priv(dev);
 
   dm9000_dbg(db, 3, %s:\n, __func__);
 @@ -761,6 +760,8 @@ dm9000_start_xmit(struct sk_buff *skb, struct
 net_device *dev)
   /* Disable all interrupts */
   iow(db, DM9000_IMR, IMR_PAR);
 
 + spin_lock(db-lock);
 +
   /* Move data to DM9000 TX RAM */
   writeb(DM9000_MWCMD, db-io_addr);
 
 @@ -784,6 +785,8 @@ dm9000_start_xmit(struct sk_buff *skb, struct
 net_device *dev)
   netif_stop_queue(dev);
   }
 
 + spin_unlock(db-lock);
 +
   /* Re-enable interrupt */
   iow(db, DM9000_IMR, IMR_PAR | IMR_PTM | IMR_PRM);
 

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: FYI: upstream-cleanup branch

[David Brownell]

On Wednesday 11 February 2009, Kumar, Purushotam wrote:
  @@ -914,7 +927,12 @@ static inline int handle_core_command(
    status = readl(host-base + DAVINCI_MMCST0);
    if (!status)
    break;
  +
    qstatus |= status;
  + if (count++  40) {
  + dev_dbg(mmc_dev(host-mmc), PIO timeout\n);
  + break;
  + }
    }
  
    if (qstatus  MMCST0_DATDNE) {
 
 I think it has potential bug. DAVINCI_MMCST0 register has been
 read (assume that either MMCST0_DXRDY or MMCST0_DRRDY was also
 set) and at same time it will break if count has reached 41.

So you suggest ... what?  Tending the fifo exactly once, and
removing that loop, would be my suggestion.


 There will be no write to FIFO and so MMCST0_DXRDY/MMCST0_DRRDY
 will not be set again and so no next interrupt which could cause
 hang. In order to fix this bug, we need to check count value before
 DAVINCI_MMCST0 register read. But, I feel we should not add any
 PIO timeout here. I checked on EVM and count has never increased
 more than 1 for high speed card.

If it it only gets to one, then there's no need for the loop in
the first place.  I'm a bit curious why that loop is there in the
first place ... it shouldn't actually be needed.

Note there's another unbounded loop in the driver, which I didn't
fix:  the main irq handler, mmc_davinci_irq(), which is calling
that handle_core_command() thing.  The handle_core() thing ought
to be the main body of the IRQ handler; without looping; and
that spurious IRQ branch should return IRQ_NONE (and never even
happen, for that matter, easily arranged).

- Dave




___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: DaVinci git updated to v2.6.29-rc4, source.mvista.com repo going away

[David Brownell]

On Wednesday 11 February 2009, Kevin Hilman wrote:
  Appended is a patch for one USB goof.  Also, the MMC driver
  is ... quite an old version.  NAND isn't current either.
 
 Hmm, this USB change is already in my tree.  And the NAND driver[1]
 is the same for me as pre-merge, and so is MMC[2].
 
 Maybe there were some problems pushing to the master repo, or 
 the kernel.org mirrors are not sync'd?
 
 Can you re-pull. I will pull a fresh copy from the master repo and try
 to see what is happening.

Grr, my bad.  I'm not sure what was with the tree I was using,
but after a pull it looks better.

Toplevel Makefile does seem to have an extra SUBARCH := arm
though.  ;)

- Dave


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [patch davinci-git 2/3] NAND: Fix raw reads with ECC syndrome layouts

[David Brownell]

On Wednesday 11 February 2009, Nori, Sekhar wrote:
 Of course, the code in nand_base.c does not accommodate this. May be
 overriding the *_syndrome()functions for davinci is the only near term
 solution?

Does it need to be described as NAND_ECC_HW_SYNDROME though?

I kind of got the feeling those code paths were pretty buggy
for the multi-chunk cases.  If you can avoid them entirely,
that would likely be a big win.  Unless you want to get into
bugfixing those parts of the NAND core...

- Dave




___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [patch davinci-git 2/3] NAND: Fix raw reads with ECC syndrome layouts

[David Brownell]

On Wednesday 11 February 2009, Allred, Daniel wrote:
 
 Revision to DM355, current OMAP-L1x7, and upcoming OMAP-L1x8,
 upcoming DM365, will all use same layout.  All data will be
 stored in data portion of page (2K page device will have four
 512-byte chunks, 4K page device will have eight 512-byte chunks,
 etc.). All ECC info (syndrome data) will be stored in the OOB/spare
 region.  The 4-bit ECC HW requires 10 bytes of ECC data for every
 512-byte data chunk so the spare layout will consist of N (4 for
 2K-page device, 8 for 4K-page device, etc.) 16 byte regions, one
 region for each 512-byte data chunk in the main data page.  The
 first six bytes of this region are open/free.  The last 10 bytes of
 this region are the bytes ECC data that correspond to the data chunk.

Sounds like a workable plan, given the ECC engine cooperates
and the MTD layer supports it.  If TI is handling all those
details, so be it.  :)

If I were doing it afresh, I'd have contiguous ECC data the
non-ECC parts of OOB data weren't fragmented ... but that
shouldn't matter much.  Newer code like UBI (and UBIFS) is
not making much use of OOB data.

- Dave


 When reading, all of the spare bytes data must first be read
 from the spare region and into local memory. The ECC info in
 these spare bytes will (must) be used, as appropriate, after
 the read of each 512-byte data chunk.   
 
 When writing, all the ECC data must be read from the HW and
 stored locally after each 512 byte chunk read.  Then that ECC
 data will be formatted as specified above and written to the
 OOB/spare region altogether after all data pages have been written.   
 
 Does that clarify anything here?
 
 Daniel J. Allred
 High Performance DSP/SoC
 Catalog DSP / Emerging End Equipment
 

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG timeout issue

[David Brownell]

On Wednesday 11 February 2009, Narnakaje, Snehaprabha wrote:
 After going through some testing, it looks like the issue is
 how we have the dm9000 interrupt configured on the DM355 EVM. 

This doesn't explain anything to me, though ...


 On DM355 EVM, we have GPIO1 configured as dm9000 interrupt line.
 May be on other boards have a dedicated dm9000 interrupt line. 
 If we have a dedicated interrupt (to which the disable/enable
 dm9000 interrupt is also tied), I think it is enough to use
 global IRQ disable/enable APIs.  

So what's the particular problem?  Something with how
GPIO interrupts are being processed?  I could believe
that ... they've not been stressed much before, and such
low-level code can hide subtle issues for a long time.

But I'm still curious why I don't see the problem.
Admittedly I'm not using NFS much, but still I would
expect to ssee *some* dm9000 issue.

- Dave


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 9/9] musb_gadget_ep0: fix unhandled IRQ

[David Brownell]

On Tuesday 10 February 2009, Sergei Shtylyov wrote:
     Though I suspect that in reality these two distinct interrupts will often 
 coalesce as well as DATA1 token should follow IN/OUT pretty quick. What a 
 racy 
 piece of hardware... :-/

Nothing very specific to this hardware, unless it's really
doing something stupid like issuing IRQs for IN/OUT instead
of just the various flavors of DATA.

Control transfers *always* have lots of adjacent packets of
odd types, so unless the hardware takes particular care to
let the software insert delays between e.g.

- SETUP/DATA then
* IN/DATA (most allow NAKing here)
* OUT/DATA (some don't, painful)
- IN/DATA and status OUT/DATA
- OUT/DATA and status IN/DATA

then there will be races there.  And delivery of SETUP is
inherently racey ... in the worst case, the host sends one
before the preceding transaction completes.  A common case
that's not quite as bad is getting a SETUP right after the
empty status ack was sent.  That case is usually preventable
by having the peripheral NAK until it's processed all the
IN/OUT data ... but again, not all hardware allows that.

- Dave

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 9/9] musb_gadget_ep0: fix unhandled IRQ

[David Brownell]

On Wednesday 04 February 2009, Sergei Shtylyov wrote:
 The EP0 code routinely ignores interrupt at end of the data phase because of
 musb_g_ep0_giveback() resetting the state machine to idle, waiting for SETUP
 phase prematurely.
 
 Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com

Does this depend on any preceding patches?


 ---
 This fixes most of the unhandled gadget interrupts that generic_interrupt() 
 and
 davinci_interrupt() have been hiding from user by faking their result and only
 emitting 5th level debug message (for what is clearly an error).

So, this should then remove the comment and DBG() from the
davinci_interrupt() and generic_interrupt() IRQ handlers,
and stop always returning IRQ_HANDLED.


I'm not sure I'd agree this is a must fix for 2.6.29 bug.
What problems does it cause ... other than a low priority
debug message appearing, when such messages are cranked up
to a serious impact on usability level?  How did you
reproduce the problem?
 
ISTR this seemed harmless, which is why its diagnostic was
low priority and the mess only got a REVISIT comment.
I'm glad to see that you seem be part way to a fix, and I'll
add a revised version (with the changes I summarized above,
and the others you mentioned) to some patches I'm checking out.

- Dave


 
  drivers/usb/musb/musb_gadget_ep0.c |1 -
  1 files changed, 1 deletion(-)
 
 Index: linux-2.6/drivers/usb/musb/musb_gadget_ep0.c
 ===
 --- linux-2.6.orig/drivers/usb/musb/musb_gadget_ep0.c
 +++ linux-2.6/drivers/usb/musb/musb_gadget_ep0.c
 @@ -197,7 +197,6 @@ service_in_request(struct musb *musb, co
  static void musb_g_ep0_giveback(struct musb *musb, struct usb_request *req)
  {
   musb_g_giveback(musb-endpoints[0].ep_in, req, 0);
 - musb-ep0_state = MUSB_EP0_STAGE_SETUP;
  }
  
  /*
 
 



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 9/9] musb_gadget_ep0: fix unhandled IRQ

[David Brownell]

On Wednesday 11 February 2009, Sergei Shtylyov wrote:
    I'm considering addition of another (tryly idle) phase because the 
 stage after the status phase completion interrupt and before the 
 RxPktRdy interrupt was clearly missed.

In answer to Greg's previous question:  looks like this patch is
rather clearly *not* 2.6.29 material.  ;)

Sergei, adding another phase to the state machine should be no
particular issue, but do keep in mind that the musb_g_ep0_state
values reflect *protocol* states right now.

That is, the model is that the various IRQ-driven transitions
should be sorted out, races and all, and then mapped to those
states.  The Mentor documentation is excessively weak about
most of the hardware state transitions (and e.g. their OTG
states are a complete mismatch to the OTG specs), so coming up
with something that mirrors hardware not protocol states isn't
very straightforward.

- Dave

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG timeout issue

[Narnakaje, Snehaprabha]

 -Original Message-
 From: David Brownell [mailto:davi...@pacbell.net]
 Sent: Wednesday, February 11, 2009 4:06 PM
 To: Narnakaje, Snehaprabha
 Cc: davinci-linux-open-source@linux.davincidsp.com; Kevin Hilman
 Subject: Re: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG
 timeout issue
 
 On Wednesday 11 February 2009, Narnakaje, Snehaprabha wrote:
  After going through some testing, it looks like the issue is
  how we have the dm9000 interrupt configured on the DM355 EVM.
 
 This doesn't explain anything to me, though ...
 
 
  On DM355 EVM, we have GPIO1 configured as dm9000 interrupt line.
  May be on other boards have a dedicated dm9000 interrupt line.
  If we have a dedicated interrupt (to which the disable/enable
  dm9000 interrupt is also tied), I think it is enough to use
  global IRQ disable/enable APIs.
 
 So what's the particular problem?  Something with how
 GPIO interrupts are being processed?  I could believe
 that ... they've not been stressed much before, and such
 low-level code can hide subtle issues for a long time.

We were trying to see why we need this additional dm9000 specific 
disable/enable interrupts in the xmit function. It seems like dm9000 ethernet 
controller being used on other boards does not require this. The difference is 
with the usage of GPIO based interrupt for dm9000, on DM355.
Ideally spin_lock_irqsave is supposed to disable interrupts locally. Does it 
mean GPIO1 interrupt or does it mean dm9000 hardware interrupt. I was trying to 
see if we have a problem here.

 
 But I'm still curious why I don't see the problem.
 Admittedly I'm not using NFS much, but still I would
 expect to ssee *some* dm9000 issue.

I think, the issue is easily (almost always) reproducible if I use a NFS root 
filesystem. If I come up other filesystems (like ramdisk) and then configure 
Ethernet, it is not always reproducible. In this case, I have seen the NETDEV 
watchdog timeouts occasionally when I ping another host from the EVM.

Thanks
Sneha

 
 - Dave
 

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 9/9] musb_gadget_ep0: fix unhandled IRQ

[Sergei Shtylyov]

David Brownell wrote:

  I'm considering addition of another (tryly idle) phase because the 
stage after the status phase completion interrupt and before the 
RxPktRdy interrupt was clearly missed.



In answer to Greg's previous question:  looks like this patch is
rather clearly *not* 2.6.29 material.  ;)


   Well, could wait indeed. DaVinci and OMAP are hiding those IRQs from user 
anyway (but my OMAP-L1x glue doesn't)...



Sergei, adding another phase to the state machine should be no
particular issue, but do keep in mind that the musb_g_ep0_state
values reflect *protocol* states right now.


   The states actually should correspond to the interrupts generated by MUSB 
(with one exception, ACKWAIT). The problem is that one state was skipped (the 
corresponding IRQ *usually* gets coalesced with a preceding one in the 
STATUS/OUT phase).



That is, the model is that the various IRQ-driven transitions
should be sorted out, races and all, and then mapped to those
states.  The Mentor documentation is excessively weak about
most of the hardware state transitions (and e.g. their OTG
states are a complete mismatch to the OTG specs), so coming up
with something that mirrors hardware not protocol states isn't
very straightforward.


   Contrarywise, it's the only viable solution I think -- since we can't see 
what happens on USB directly and have to rely on MUSB as a proxy.
   And anyway, the ACKWAIT state doesn't seem to correspond to anything in 
the USB protocol -- it looks like artificial addition.



- Dave


WBR, Sergei

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 9/9] musb_gadget_ep0: fix unhandled IRQ

[Sergei Shtylyov]

David Brownell wrote:

   Though I suspect that in reality these two distinct interrupts will often 
coalesce as well as DATA1 token should follow IN/OUT pretty quick. What a racy 
piece of hardware... :-/



Nothing very specific to this hardware, unless it's really
doing something stupid like issuing IRQs for IN/OUT instead
of just the various flavors of DATA.


   Well, it does issue SetupEnd interrupt on receiving IN/OUT token -- if 
they are unexpected ATM. That's off the top of my head.



Control transfers *always* have lots of adjacent packets of
odd types, so unless the hardware takes particular care to
let the software insert delays between e.g.



- SETUP/DATA then
* IN/DATA (most allow NAKing here)
* OUT/DATA (some don't, painful)
- IN/DATA and status OUT/DATA
- OUT/DATA and status IN/DATA



then there will be races there.  And delivery of SETUP is
inherently racey ... in the worst case, the host sends one
before the preceding transaction completes.


   That is already handled.


A common case that's not quite as bad is getting a SETUP right after the
empty status ack was sent.


   Handled too, however I haven't seen this happening so far: there are 
always at least 2 distinct interrupts between the last data packet sent by 
device and SETUP received -- can be all spec'ed 3 interrupts sometimes as it 
turned out.



- Dave


WBR, Sergei

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG timeout issue

[David Brownell]

On Wednesday 11 February 2009, Narnakaje, Snehaprabha wrote:
 
  So what's the particular problem?  Something with how
  GPIO interrupts are being processed?  I could believe
  that ... they've not been stressed much before, and such
  low-level code can hide subtle issues for a long time.
 
 We were trying to see why we need this additional dm9000
 specific disable/enable interrupts in the xmit function.
 It seems like dm9000 ethernet controller being used on
 other boards does not require this. The difference is with
 the usage of GPIO based interrupt for dm9000, on DM355.

That still doesn't help me understand what's going on.
I'm guessing you don't quite know yet either, but this
tweak seems to be a good clue.


 Ideally spin_lock_irqsave is supposed to disable interrupts
 locally. Does it mean GPIO1 interrupt or does it mean dm9000
 hardware interrupt.

Neither.  It clears the CPU's IRQ-enable bit ... not the
GPIO bank 0 IRQ enable, and not the dm9000-internal enable.

While that IRQ is being processed, I seem to recall that the
bank 0 IRQ is masked in the toplevel DaVinci IRQ controller;
as well as the CPU's IRQ-enable bit.

Is there maybe a level vs edge triggering issue?

- Dave

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 2/9] musb_host: fix endpoint allocation

[David Brownell]

On Wednesday 04 February 2009, Sergei Shtylyov wrote:
 The driver prevents using the same numbered Rx/Tx endpoints simultaneously for
 the periodic transfers -- which would actually be correct unless they share 
 the
 same FIFO. Use 'in_qh' and 'out_qh' fields of the 'struct musb_hw_ep' to check
 the endpoint's business and get rid of now completely useless 'periodic' array
 in the 'struct musb'.  While at it, optimize the loop induction variable in 
 the
 endpoint lookup code and remove duplicate/unneeded code elsewhere...
 
 Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com

Your patch comments need improvement.  This would better be
titled rewrite endpoint allocation, and the description
should highlight make better use of resources.  Not using
something that's available is sub-optimal, but rarely a bug.

This doesn't seem to fix anything hurtful; so, it's not
for 2.6.29 merge.

What I'm going to do is send a replacement with a better
description and my signoff.


 
  drivers/usb/musb/musb_core.h |1 -
  drivers/usb/musb/musb_host.c |   27 ++-
  2 files changed, 10 insertions(+), 18 deletions(-)
 
 Index: linux-2.6/drivers/usb/musb/musb_core.h
 ===
 --- linux-2.6.orig/drivers/usb/musb/musb_core.h
 +++ linux-2.6/drivers/usb/musb/musb_core.h
 @@ -331,7 +331,6 @@ struct musb {
   struct list_headcontrol;/* of musb_qh */
   struct list_headin_bulk;/* of musb_qh */
   struct list_headout_bulk;   /* of musb_qh */
 - struct musb_qh  *periodic[32];  /* tree of interrupt+iso */
  #endif
  
   /* called with IRQs blocked; ON/nonzero implies starting a session,
 Index: linux-2.6/drivers/usb/musb/musb_host.c
 ===
 --- linux-2.6.orig/drivers/usb/musb/musb_host.c
 +++ linux-2.6/drivers/usb/musb/musb_host.c
 @@ -400,7 +400,6 @@ musb_giveback(struct musb_qh *qh, struct
* de-allocated if it's tracked and allocated;
* and where we'd update the schedule tree...
*/
 - musb-periodic[ep-epnum] = NULL;
   kfree(qh);
   qh = NULL;
   break;
 @@ -1716,31 +1715,26 @@ static int musb_schedule(
  
   /* else, periodic transfers get muxed to other endpoints */
  
 - /* FIXME this doesn't consider direction, so it can only
 -  * work for one half of the endpoint hardware, and assumes
 -  * the previous cases handled all non-shared endpoints...
 -  */
 -
 - /* we know this qh hasn't been scheduled, so all we need to do
 + /*
 +  * We know this qh hasn't been scheduled, so all we need to do
* is choose which hardware endpoint to put it on ...
*
* REVISIT what we really want here is a regular schedule tree
 -  * like e.g. OHCI uses, but for now musb-periodic is just an
 -  * array of the _single_ logical endpoint associated with a
 -  * given physical one (identity mapping logical-physical).
 -  *
 -  * that simplistic approach makes TT scheduling a lot simpler;
 -  * there is none, and thus none of its complexity...
 +  * like e.g. OHCI uses.
*/
   best_diff = 4096;
   best_end = -1;
  
 - for (epnum = 1; epnum  musb-nr_endpoints; epnum++) {
 + for (epnum = 1, hw_ep = musb-endpoints + 1; epnum  musb-nr_endpoints;
 +  epnum++, hw_ep++) {
   int diff;
  
 - if (musb-periodic[epnum])
 + if (is_in || hw_ep-is_shared_fifo) {
 + if (hw_ep-in_qh  != NULL)
 + continue;
 + } else  if (hw_ep-out_qh != NULL)
   continue;
 - hw_ep = musb-endpoints[epnum];
 +
   if (hw_ep == musb-bulk_ep)
   continue;
  
 @@ -1769,7 +1763,6 @@ static int musb_schedule(
   idle = 1;
   qh-mux = 0;
   hw_ep = musb-endpoints + best_end;
 - musb-periodic[best_end] = qh;
   DBG(4, qh %p periodic slot %d\n, qh, best_end);
  success:
   if (head) {
 
 



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 1/9] musb_host: fix musb_host_tx() for shared endpoint FIFO

[David Brownell]

On Wednesday 04 February 2009, Sergei Shtylyov wrote:
 From: Dmitry Krivoschekov dkrivosche...@ru.mvista.com
 
 Input queue should be used for Tx if an endpoint's FIFO is shared.

(Because there's only the one queue in such cases...)

 
 Signed-off-by: Dmitry Krivoschekov dkrivosche...@ru.mvista.com
 Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com

Acked-by: David Brownell dbrown...@users.sourceforge.net

Greg, this bugfix looks appropriate for 2.6.29-rc.

I'm not going to suggest -stable backports for any of
these fixes, since the MUSB codes hasn't really been
usable previously (sigh).


Also:  note that I'm just reviewing these, not trying
to test them on half a dozen varieties of hardware
using this driver.


 
 ---
 The patch is against the recent Linus' kernel...
 
  drivers/usb/musb/musb_host.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletion(-)
 
 Index: mainline/drivers/usb/musb/musb_host.c
 ===
 --- mainline.orig/drivers/usb/musb/musb_host.c
 +++ mainline/drivers/usb/musb/musb_host.c
 @@ -1155,7 +1155,8 @@ void musb_host_tx(struct musb *musb, u8 
   struct urb  *urb;
   struct musb_hw_ep   *hw_ep = musb-endpoints + epnum;
   void __iomem*epio = hw_ep-regs;
 - struct musb_qh  *qh = hw_ep-out_qh;
 + struct musb_qh  *qh = hw_ep-is_shared_fifo ? hw_ep-in_qh
 + : hw_ep-out_qh;
   u32 status = 0;
   void __iomem*mbase = musb-mregs;
   struct dma_channel  *dma;
 
 



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 2/9] musb_host: fix endpoint allocation

[Sergei Shtylyov]

Hello.

David Brownell wrote:


The driver prevents using the same numbered Rx/Tx endpoints simultaneously for
the periodic transfers -- which would actually be correct unless they share the
same FIFO. Use 'in_qh' and 'out_qh' fields of the 'struct musb_hw_ep' to check
the endpoint's business and get rid of now completely useless 'periodic' array
in the 'struct musb'.  While at it, optimize the loop induction variable in the
endpoint lookup code and remove duplicate/unneeded code elsewhere...

Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com



Your patch comments need improvement.  This would better be
titled rewrite endpoint allocation, and the description
should highlight make better use of resources.


  No, the previous scheme was just based on the wrong assumption.


Not using something that's available is sub-optimal, but rarely a bug.
  


  Well, the patch that this one replaced was classified a s a fix and 
was in Greg's usb.current/ for some time (until I requested its removal 
due to its brokennes). This is only a replacement, so you should've 
really spoken up several months earlier. ;-)



This doesn't seem to fix anything hurtful; so, it's not
for 2.6.29 merge.

What I'm going to do is send a replacement with a better
description and my signoff.
  


  I can only be happy if someone writes the patch description for me. :-)

WBR, Sergei



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 9/9] musb_gadget_ep0: fix unhandled IRQ

[Sergei Shtylyov]

Hello.

David Brownell wrote:


The EP0 code routinely ignores interrupt at end of the data phase because of
musb_g_ep0_giveback() resetting the state machine to idle, waiting for SETUP
phase prematurely.

Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com



Does this depend on any preceding patches?
  


 Preceding patches don't touch this file, if you haven't noticed.


---
This fixes most of the unhandled gadget interrupts that generic_interrupt() and
davinci_interrupt() have been hiding from user by faking their result and only
emitting 5th level debug message (for what is clearly an error).



So, this should then remove the comment and DBG() from the
davinci_interrupt() and generic_interrupt() IRQ handlers,
and stop always returning IRQ_HANDLED.
  


  Well, that's another problem. But if you insist, I can do that.


I'm not sure I'd agree this is a must fix for 2.6.29 bug.
What problems does it cause ... other than a low priority
debug message appearing,


  Low priority debug message where the error message was more 
appropriate, you mean? :-)



when such messages are cranked up
to a serious impact on usability level?  How did you
reproduce the problem?
  


   By *not* ignoring the musb_interrupt() return value on OMAP-L137 -- 
and doing t for a good reason. :-(



ISTR this seemed harmless, which is why its diagnostic was
low priority and the mess only got a REVISIT comment.
  


  Which had never been revisited of course, until I had to look into it 
. :-)



- Dave
  


WBR, Sergei




___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

DM355 DVSDK's audio

[weixin Li]

Hi,
 
I am playing DM355 EVM's DVSDK out-of-box demo program. In encodedecode demo, 
I can get video playing on the screen but can't get audio on. Is there anybody 
know why and how to turn audio on?
 
Thanks,
Weixin___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG timeout issue

[Narnakaje, Snehaprabha]

 -Original Message-
 From: David Brownell [mailto:davi...@pacbell.net]
 Sent: Wednesday, February 11, 2009 5:46 PM
 To: Narnakaje, Snehaprabha
 Cc: davinci-linux-open-source@linux.davincidsp.com
 Subject: Re: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG
 timeout issue
 
 On Wednesday 11 February 2009, Narnakaje, Snehaprabha wrote:
 
   So what's the particular problem?  Something with how
   GPIO interrupts are being processed?  I could believe
   that ... they've not been stressed much before, and such
   low-level code can hide subtle issues for a long time.
 
  We were trying to see why we need this additional dm9000
  specific disable/enable interrupts in the xmit function.
  It seems like dm9000 ethernet controller being used on
  other boards does not require this. The difference is with
  the usage of GPIO based interrupt for dm9000, on DM355.
 
 That still doesn't help me understand what's going on.
 I'm guessing you don't quite know yet either, but this
 tweak seems to be a good clue.

You are right. I have not fully understood why it fixes the issue.

 
 
  Ideally spin_lock_irqsave is supposed to disable interrupts
  locally. Does it mean GPIO1 interrupt or does it mean dm9000
  hardware interrupt.
 
 Neither.  It clears the CPU's IRQ-enable bit ... not the
 GPIO bank 0 IRQ enable, and not the dm9000-internal enable.
 
 While that IRQ is being processed, I seem to recall that the
 bank 0 IRQ is masked in the toplevel DaVinci IRQ controller;
 as well as the CPU's IRQ-enable bit.
 
 Is there maybe a level vs edge triggering issue?

I had tried to change the dm9000 IRQ resource to falling edge (instead of 
rising edge), but that didn't help.

Sneha

 
 - Dave

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 9/9] musb_gadget_ep0: fix unhandled IRQ

[David Brownell]

On Wednesday 11 February 2009, Sergei Shtylyov wrote:
 Hello.
 
 David Brownell wrote:
 
  The EP0 code routinely ignores interrupt at end of the data phase because 
  of
  musb_g_ep0_giveback() resetting the state machine to idle, waiting for 
  SETUP
  phase prematurely.
 
  Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com
  
 
  Does this depend on any preceding patches?

 
   Preceding patches don't touch this file, if you haven't noticed.

I don't mean just textually ... there are many kinds of dependency.
Like, maybe it's really only viable given other bugfixes.  And the
default assumption is that patches in a series depend on preceding
patches; but I suspected this one wouldn't.


  ---
  This fixes most of the unhandled gadget interrupts that 
  generic_interrupt() and
  davinci_interrupt() have been hiding from user by faking their result and 
  only
  emitting 5th level debug message (for what is clearly an error).
  
 
  So, this should then remove the comment and DBG() from the
  davinci_interrupt() and generic_interrupt() IRQ handlers,
  and stop always returning IRQ_HANDLED.

 
Well, that's another problem. But if you insist, I can do that.

It's all part of the same problem.  The reason that code exists
is because of the bug you say this fixes.  If it's still needed,
then this bug isn't fully fixed by $SUBJECT patch ...


  I'm not sure I'd agree this is a must fix for 2.6.29 bug.
  What problems does it cause ... other than a low priority
  debug message appearing,
 
Low priority debug message where the error message was more 
 appropriate, you mean? :-)

If it caused no problems, it was no error.  That's
why it's a low priority debug message.  :)


  when such messages are cranked up
  to a serious impact on usability level?  How did you
  reproduce the problem?

 
 By *not* ignoring the musb_interrupt() return value on OMAP-L137 -- 
 and doing t for a good reason. :-(

OK.  I couldn't remember how common these were.  Common
enough to notice, yes -- but I don't recall if they only
came out in stress tests, or in real-world loads.


  ISTR this seemed harmless, which is why its diagnostic was
  low priority and the mess only got a REVISIT comment.

 
Which had never been revisited of course, until I had to look into it 
 . :-)

I think there's a certain tendancy for folk to want to
take a break from this driver code after getting sufficiently
bloodied by the battle.  ;)

It's gotten much better over time, but the original codebase
was truly horrendous.  So we're quite glad to see folk
contributing fixes like yours!

- Dave


 
  - Dave

 
 WBR, Sergei
 
 
 
 



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG timeout issue

[David Brownell]

On Wednesday 11 February 2009, Narnakaje, Snehaprabha wrote:
 
   Ideally spin_lock_irqsave is supposed to disable interrupts
   locally. Does it mean GPIO1 interrupt or does it mean dm9000
   hardware interrupt.
  
  Neither.  It clears the CPU's IRQ-enable bit ... not the
  GPIO bank 0 IRQ enable, and not the dm9000-internal enable.
  
  While that IRQ is being processed, I seem to recall that the
  bank 0 IRQ is masked in the toplevel DaVinci IRQ controller;
  as well as the CPU's IRQ-enable bit.
  
  Is there maybe a level vs edge triggering issue?
 
 I had tried to change the dm9000 IRQ resource to falling edge
 (instead of rising edge), but that didn't help. 

You might try making it use the dedicated GPIO1 IRQ instead
of going through the GPIO controller.  In that case, specify
it as a level IRQ (I think).  If that works, it'll indicate
some kind of problem in the GPIO IRQ chaining.

Thing is, I've never seen those IRQs work.  I think it may
have had something to do with having the IRQ for that bank
of GPIOs enabled.  There was never enough incentive to chase
down whatever problem it was ... at least, for me!

- Dave

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 9/9] musb_gadget_ep0: fix unhandled IRQ

[Sergei Shtylyov]

Hello.

David Brownell wrote:


David Brownell wrote:


The EP0 code routinely ignores interrupt at end of the data phase because of
musb_g_ep0_giveback() resetting the state machine to idle, waiting for SETUP
phase prematurely.

Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com



Does this depend on any preceding patches?
  
  

  Preceding patches don't touch this file, if you haven't noticed.



I don't mean just textually ... there are many kinds of dependency.
Like, maybe it's really only viable given other bugfixes.  And the
default assumption is that patches in a series depend on preceding
patches; but I suspected this one wouldn't.
  


  And you were right...


---
This fixes most of the unhandled gadget interrupts that generic_interrupt() and
davinci_interrupt() have been hiding from user by faking their result and only
emitting 5th level debug message (for what is clearly an error).



So, this should then remove the comment and DBG() from the
davinci_interrupt() and generic_interrupt() IRQ handlers,
and stop always returning IRQ_HANDLED.
  
  

   Well, that's another problem. But if you insist, I can do that.



It's all part of the same problem.  The reason that code exists
is because of the bug you say this fixes.  If it's still needed,
then this bug isn't fully fixed by $SUBJECT patch ...
  


  I've already wrttien that it's not completely fixed (even in the 
original patch comment I said majority of cases).



when such messages are cranked up
to a serious impact on usability level?  How did you
reproduce the problem?
  
  
By *not* ignoring the musb_interrupt() return value on OMAP-L137 -- 
and doing t for a good reason. :-(



OK.  I couldn't remember how common these were.


  They happended at end of *every* control transfer for me.


Common enough to notice, yes -- but I don't recall if they only
came out in stress tests, or in real-world loads.
  


  No stressing -- just the usual interchange during the device enumeration.


ISTR this seemed harmless, which is why its diagnostic was
low priority and the mess only got a REVISIT comment.
  
  
   Which had never been revisited of course, until I had to look into it 
. :-)



I think there's a certain tendancy for folk to want to
take a break from this driver code after getting sufficiently
bloodied by the battle.  ;)
  


  In my case it's usually forced break because they switch me to 
something other... like this damned MUSB thing (still better than KGDB 
though).



It's gotten much better over time, but the original codebase
was truly horrendous.


  I imagine...


So we're quite glad to see folk contributing fixes like yours!
  


  Well, someone has to do it... :-)
\
WBR, Sergei



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 3/8] musb_host: fix urb_dequeue() method (take 2)

[David Brownell]

On Wednesday 04 February 2009, Sergei Shtylyov wrote:
 The urb_dequeue() method forgets to unlink 'struct musb_qh' from the 
 control/
 bulk schedule list when an URB being cancelled is the only one queued to its
 endpoint, which will cause musb_advance_schedule() to block once it reaches
 'struct musb_qh' with now empty URB list, and so URBs queued for other 
 control/
 bulk endpoints after the one being dequeued will not be served. Hence add code
 to unlink and free 'struct musb_qh' if its URB list emptied to this method and
 remove now useless check from musb_advance_schedule().
 
 The only exception case is when we're called from the driver's callback --
 musb_giveback() doesn't expect us to pull out 'qh' from under it (it'll kill
 this qh later anyway) and we want to keep around a qh with is_ready flag clear
 because some drivers like usbaudio.c do submit a new URB after cancelling all
 pending ones which leads to URB being started when it shouldn't be and started
 all over again after the control returns to musb_giveback()...
 
 Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com

I'm forwarding a slightly tweaked (slimmed-down, improved
patch comment) version to Greg for the 2.6.29-rc series.

Thanks.

 
 ---
 The patch is against the recent Linus' kernel...
 
  drivers/usb/musb/musb_host.c |   16 ++--
  1 files changed, 14 insertions(+), 2 deletions(-)
 
 Index: linux-2.6/drivers/usb/musb/musb_host.c
 ===
 --- linux-2.6.orig/drivers/usb/musb/musb_host.c
 +++ linux-2.6/drivers/usb/musb/musb_host.c
 @@ -431,7 +431,7 @@ musb_advance_schedule(struct musb *musb,
   else
   qh = musb_giveback(qh, urb, urb-status);
  
 - if (qh  qh-is_ready  !list_empty(qh-hep-urb_list)) {
 + if (qh != NULL  qh-is_ready) {
   DBG(4, ... next ep%d %cX urb %p\n,
   hw_ep-epnum, is_in ? 'R' : 'T',
   next_urb(qh));
 @@ -2071,7 +2071,19 @@ static int musb_urb_dequeue(struct usb_h
   ret = 0;
   qh-is_ready = 0;
   __musb_giveback(musb, urb, 0);
 - qh-is_ready = ready;
 +
 + /*
 +  * If the URB list has emptied, it's time to kill this qh.
 +  * However, if this was called from the driver callback,
 +  * we don't really want to do it now, deferring it until
 +  * we return to musb_giveback(), or bad things will happen...
 +  */
 + if (ready  list_empty(qh-hep-urb_list)) {
 + qh-hep-hcpriv = NULL;
 + list_del(qh-ring);
 + kfree(qh);
 + } else
 + qh-is_ready = ready;
   } else
   ret = musb_cleanup_urb(urb, qh, urb-pipe  USB_DIR_IN);
  done:
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 4/9] musb_host: fix endpoint_disable() method (take 2)

[David Brownell]

On Wednesday 04 February 2009, Sergei Shtylyov wrote:
 @@ -2141,13 +2142,22 @@ musb_h_disable(struct usb_hcd *hcd, stru
  
 /* cleanup */
 musb_cleanup_urb(urb, qh, urb-pipe  USB_DIR_IN);
 -   } else
 -   urb = NULL;
 -
 -   /* then just nuke all the others */
 -   list_for_each_entry_safe_from(urb, tmp, hep-urb_list, urb_list)
 -   musb_giveback(qh, urb, -ESHUTDOWN);
  
 +   /* Then just nuke all the others */
 +   while (!list_empty(hep-urb_list)) {
 +   urb = next_urb(qh);
 +   urb-status = -ESHUTDOWN;
 +   musb_advance_schedule(musb, urb, qh-hw_ep, is_in);
 +   }
 +   } else {
 +   while (!list_empty(hep-urb_list))
 +   __musb_giveback(musb, next_urb(qh), -ESHUTDOWN);

Why does this have two different code paths for the
unlink everything that the hardware doesn't have its
mittens on branch?

It certainly *looks* goofy this way, and if it's not
buggy today then it'll probably grow some in the future.

Could you update this to settle on a single while()
loop?  I'd suggest the else branch as being simpler.

Then this patch should be suitable for 2.6.29-rc, as
a fix for an infrequent oops.

- Dave

  

 +
 +   hep-hcpriv = NULL;
 +   list_del(qh-ring);
 +   kfree(qh);
 +   }
 +exit:
 spin_unlock_irqrestore(musb-lock, flags);
  }
  
 



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 4/9] musb_host: fix endpoint_disable() method (take 2)

[David Brownell]

On Wednesday 11 February 2009, David Brownell wrote:
 Why does this have two different code paths for the
 unlink everything that the hardware doesn't have its
 mittens on branch?
 
 It certainly *looks* goofy this way, and if it's not
 buggy today then it'll probably grow some in the future.

Whoops, I see.  The answer should have been in a comment;
I'll fix that and send to Greg.

Answer to my question:  because one branch must advance
the bulk or control queue the endpoint was on, but the
other branch doesn't.


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 4/9] musb_host: fix endpoint_disable() method (take 2)

[Sergei Shtylyov]

Hello.

David Brownell wrote:


Why does this have two different code paths for the
unlink everything that the hardware doesn't have its
mittens on branch?

It certainly *looks* goofy this way, and if it's not
buggy today then it'll probably grow some in the future.



Whoops, I see.  The answer should have been in a comment;
  


  Thank goodness. I hoped that I hadn't spent the time writing the 
patch description in vain too... :-/



I'll fix that and send to Greg.

Answer to my question:  because one branch must advance
the bulk or control queue the endpoint was on, but the
other branch doesn't.


  Yes. The other branch also must not call musb_giveback() because thel 
latter assumes to be called on active qh and will e.g. spoil the saved 
toggle state otherwise.


WBR, Sergei



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 4/9] musb_host: fix endpoint_disable() method (take 2)

[Sergei Shtylyov]

Hello.

David Brownell wrote:


@@ -2141,13 +2142,22 @@ musb_h_disable(struct usb_hcd *hcd, stru
 
/* cleanup */

musb_cleanup_urb(urb, qh, urb-pipe  USB_DIR_IN);
-   } else
-   urb = NULL;
-
-   /* then just nuke all the others */
-   list_for_each_entry_safe_from(urb, tmp, hep-urb_list, urb_list)
-   musb_giveback(qh, urb, -ESHUTDOWN);
 
+   /* Then just nuke all the others */

+   while (!list_empty(hep-urb_list)) {
+   urb = next_urb(qh);
+   urb-status = -ESHUTDOWN;
+   musb_advance_schedule(musb, urb, qh-hw_ep, is_in);
+   }
+   } else {
+   while (!list_empty(hep-urb_list))
+   __musb_giveback(musb, next_urb(qh), -ESHUTDOWN);



Why does this have two different code paths for the
unlink everything that the hardware doesn't have its
mittens on branch?
  


  Exactly because this cases needs to be handled differently. Re-read 
the patch description please.



It certainly *looks* goofy this way, and if it's not
  


 What *ceartainly* looked goofy is the code that was there before 
this patch.



buggy today then it'll probably grow some in the future.
  


  Care to elaborate why?


Could you update this to settle on a single while()
loop?


  Certainly not.


I'd suggest the else branch as being simpler.
  


  Think again please and re-read the patch description.


- Dave
  


WBR., Sergei



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Gamma correction in VENC

[Lori]

Sorry for the mistake, the dm355 output RGB565 format.to zuowenping: The ths8200 dman_cntl is 0x71. = Original Message =











the dm355 only can supply 16 bit 

rgb,so the ths8200 dman_cntl register must modify to 0x71,not default 

0x70!

 

 

2009-02-11 





zuowenping 







发件人： Lori 

发送时间： 2009-02-11  14:07:07 



收件人： 

davinci-linux-open-source@linux.davincidsp.com 

抄送： 

主题： Gamma correction in VENC 



 

Dear all:I am using the ths8200 to output 

VGA format signal, so the dm355 must supply the RGB656 format. But in this 

situation the display on monitor lost some color gradation. The venc provides 

the gamma correction. I want konw if it is useful for my problem. And the gamma 

correction use only two register, who can give me an example or advice about how 

to use them in program? ___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 5/9] musb_host: fix data toggle saving with shared FIFO

[David Brownell]

On Wednesday 04 February 2009, Sergei Shtylyov wrote:
 For some strange reason musb_giveback() decides that it's always IN transfer
 in case the hardware endpoint has shared FIFO.  This causes musb_save_toggle()
 to read the toggle state from the RXCSR register instead of TXCSR; it also may
 cause unneeded reloading of the Rx endpoint registers.
 
 Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com

Acked-by: David Brownell dbrown...@users.sourceforge.net

Appropriate for 2.6.29-rc ... trashing the toggle
is badness.  One reason this bug has stayed around
for a long time is that the shared FIFO configuration
has primarily been used for periodic IN endpoints.


 
 ---
 The patch is against the recent Linus' kernel.
 
  drivers/usb/musb/musb_host.c |7 +--
  1 files changed, 1 insertion(+), 6 deletions(-)
 
 Index: linux-2.6/drivers/usb/musb/musb_host.c
 ===
 --- linux-2.6.orig/drivers/usb/musb/musb_host.c
 +++ linux-2.6/drivers/usb/musb/musb_host.c
 @@ -335,16 +335,11 @@ musb_save_toggle(struct musb_hw_ep *ep, 
  static struct musb_qh *
  musb_giveback(struct musb_qh *qh, struct urb *urb, int status)
  {
 - int is_in;
   struct musb_hw_ep   *ep = qh-hw_ep;
   struct musb *musb = ep-musb;
 + int is_in = usb_pipein(urb-pipe);
   int ready = qh-is_ready;
  
 - if (ep-is_shared_fifo)
 - is_in = 1;
 - else
 - is_in = usb_pipein(urb-pipe);
 -
   /* save toggle eagerly, for paranoia */
   switch (qh-type) {
   case USB_ENDPOINT_XFER_BULK:
 
 



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 4/9] musb_host: fix endpoint_disable() method (take 2)

[David Brownell]

On Wednesday 11 February 2009, Sergei Shtylyov wrote:
  Answer to my question:  because one branch must advance
  the bulk or control queue the endpoint was on, but the
  other branch doesn't.
 
    Yes. The other branch also must not call musb_giveback() because thel 
 latter assumes to be called on active qh and will e.g. spoil the saved 
 toggle state otherwise.

Saved toggle state is never-no-mind in this function
though, since the endpoint is going away.

That might change in the future, if we grow some sort
of just empty the queue method instead of the current
empty queue and disable endpoint.

- Dave


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 4/9] musb_host: fix endpoint_disable() method (take 2)

[Sergei Shtylyov]

Hello.

David Brownell wrote:


Answer to my question:  because one branch must advance
the bulk or control queue the endpoint was on, but the
other branch doesn't.
  
   Yes. The other branch also must not call musb_giveback() because thel 
latter assumes to be called on active qh and will e.g. spoil the saved 
toggle state otherwise.



Saved toggle state is never-no-mind in this function
though, since the endpoint is going away.
  


  Sigh... it will spoil the state of another, curently active endpoint, 
of course.


WBR, Sergei



___
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 2/2] clkdev: don't fail for dev_id-only or con_id-only matches

[Kevin Hilman]

If clk_find() is called with either parameter being NULL, it will fail
even if a match is found for the non-NULL parameter.

According to the comments, it looks like if either is present it must
match.  But due to the ranking system, I think it is better to just
allow a lower-ranking match to succeed rather than not allow any
match.

Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/common/clkdev.c |   14 ++
 1 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/arm/common/clkdev.c b/arch/arm/common/clkdev.c
index 1037bba..b8fcab2 100644
--- a/arch/arm/common/clkdev.c
+++ b/arch/arm/common/clkdev.c
@@ -41,15 +41,13 @@ static struct clk *clk_find(const char *dev_id, const char 
*con_id)
 
list_for_each_entry(p, clocks, node) {
match = 0;
-   if (p-dev_id) {
-   if (!dev_id || strcmp(p-dev_id, dev_id))
-   continue;
-   match += 2;
+   if (p-dev_id  dev_id) {
+   if (!strcmp(p-dev_id, dev_id))
+   match += 2;
}
-   if (p-con_id) {
-   if (!con_id || strcmp(p-con_id, con_id))
-   continue;
-   match += 1;
+   if (p-con_id  con_id) {
+   if (!strcmp(p-con_id, con_id))
+   match += 1;
}
if (match == 0)
continue;
-- 
1.6.1.2


___
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 0/2] davinci WIP: convert to clkdev infrastructure

[Kevin Hilman]

This series is a first pass at converting the DaVinci git kernel over
to using the new clkdev infrastructure in 2.6.29.

Applies on current davinci HEAD, and tested on dm6446, dm355 and dm6467.

Kevin Hilman (2):
  davinci: clkdev: convert to new clkdev infrastructure
  clkdev: don't fail for dev_id-only or con_id-only matches

 arch/arm/Kconfig|1 +
 arch/arm/common/clkdev.c|   14 ++---
 arch/arm/mach-davinci/clock.c   |   39 ++-
 arch/arm/mach-davinci/clock.h   |   15 +
 arch/arm/mach-davinci/devices.c |4 -
 arch/arm/mach-davinci/dm355.c   |   90 +-
 arch/arm/mach-davinci/dm644x.c  |   87 +
 arch/arm/mach-davinci/dm646x.c  |   67 +++-
 arch/arm/mach-davinci/include/mach/clkdev.h |   13 
 arch/arm/mach-davinci/include/mach/clock.h  |1 -
 arch/arm/mach-davinci/time.c|   17 +++--
 drivers/i2c/busses/i2c-davinci.c|2 +-
 drivers/mmc/host/davinci_mmc.c  |2 +-
 drivers/net/davinci_emac.c  |2 +-
 drivers/watchdog/davinci_wdt.c  |2 +-
 sound/soc/davinci/davinci-i2s.c |6 +--
 16 files changed, 198 insertions(+), 164 deletions(-)
 create mode 100644 arch/arm/mach-davinci/include/mach/clkdev.h


___
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 1/2] davinci: clkdev: convert to new clkdev infrastructure

[Kevin Hilman]

Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/Kconfig|1 +
 arch/arm/mach-davinci/clock.c   |   39 ++-
 arch/arm/mach-davinci/clock.h   |   15 +
 arch/arm/mach-davinci/devices.c |4 -
 arch/arm/mach-davinci/dm355.c   |   90 +-
 arch/arm/mach-davinci/dm644x.c  |   87 +
 arch/arm/mach-davinci/dm646x.c  |   67 +++-
 arch/arm/mach-davinci/include/mach/clkdev.h |   13 
 arch/arm/mach-davinci/include/mach/clock.h  |1 -
 arch/arm/mach-davinci/time.c|   17 +++--
 drivers/i2c/busses/i2c-davinci.c|2 +-
 drivers/mmc/host/davinci_mmc.c  |2 +-
 drivers/net/davinci_emac.c  |2 +-
 drivers/watchdog/davinci_wdt.c  |2 +-
 sound/soc/davinci/davinci-i2s.c |6 +--
 15 files changed, 192 insertions(+), 156 deletions(-)
 create mode 100644 arch/arm/mach-davinci/include/mach/clkdev.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9bf3cb0..56094ed 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -560,6 +560,7 @@ config ARCH_DAVINCI
select HAVE_CLK
select ZONE_DMA
select HAVE_IDE
+   select COMMON_CLKDEV
 
help
  Support for TI's DaVinci platform.
diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index ff8b253..4cae71c 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -30,6 +30,7 @@ static LIST_HEAD(clocks);
 static DEFINE_MUTEX(clocks_mutex);
 static DEFINE_SPINLOCK(clockfw_lock);
 
+#ifndef CONFIG_COMMON_CLKDEV
 extern void davinci_psc_config(unsigned int domain, unsigned int id, char 
enable);
 
 /*
@@ -137,6 +138,7 @@ void clk_put(struct clk *clk)
module_put(clk-owner);
 }
 EXPORT_SYMBOL(clk_put);
+#endif /* CONFIG_COMMON_CLKDEV */
 
 static unsigned psc_domain(struct clk *clk)
 {
@@ -372,31 +374,32 @@ static void __init clk_pll_init(struct clk *clk)
pr_debug(] -- %lu MHz output.\n, clk-rate / 100);
 }
 
-int __init davinci_clk_init(struct clk *clocks[])
-{
-   struct clk *clkp;
-   int i = 0;
+int __init davinci_clk_init(struct davinci_clk *clocks)
+  {
+   struct davinci_clk *c;
+   struct clk *clk;
+  
+   printk(%s\n, __func__);
+   for ( c = clocks; c-lk.clk; c++ ) {
+   clk = c-lk.clk;
 
-   while ((clkp = clocks[i++])) {
-   if (clkp-pll_data)
-   clk_pll_init(clkp);
+   printk(%s: %s\n, __func__, c-lk.con_id);
+   if (clk-pll_data)
+   clk_pll_init(clk);
 
/* Calculate rates for PLL-derived clocks */
-   else if (clkp-flags  CLK_PLL)
-   clk_sysclk_recalc(clkp);
-
-   if (clkp-lpsc)
-   clkp-flags |= CLK_PSC;
+   else if (clk-flags  CLK_PLL)
+   clk_sysclk_recalc(clk);
 
-   clk_register(clkp);
+   if (clk-lpsc)
+   clk-flags |= CLK_PSC;
 
-   /* FIXME: remove equivalent special-cased code from
-* davinci_psc_init() once cpus list *all* clocks.
-*/
+   clkdev_add(c-lk);
+   clk_register(clk);
 
/* Turn on clocks that Linux doesn't otherwise manage */
-   if (clkp-flags  ALWAYS_ENABLED)
-   clk_enable(clkp);
+   if (clk-flags  ALWAYS_ENABLED)
+   clk_enable(clk);
}
 
return 0;
diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index c1191df..24cfed4 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
@@ -12,6 +12,7 @@
 #define __ARCH_ARM_DAVINCI_CLOCK_H
 
 #include linux/list.h
+#include asm/clkdev.h
 
 #define DAVINCI_PLL1_BASE 0x01c40800
 #define DAVINCI_PLL2_BASE 0x01c40c00
@@ -76,7 +77,21 @@ struct clk {
 #define CLK_PLLBIT(4) /* PLL-derived clock */
 #define PRE_PLL BIT(5) /* source is before PLL mult/div */
 
+struct davinci_clk {
+   struct clk_lookup lk;
+};
+
+#define CLK(dev, con, ck)  \
+   {   \
+   .lk = { \
+   .dev_id = dev,  \
+   .con_id = con,  \
+   .clk = ck,  \
+   },  \
+   }
+
 int davinci_clk_associate(struct device *dev, const char *logical_clockname,
  const char *physical_clockname);
 
+int davinci_clk_init(struct davinci_clk *clocks);
 #endif
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index a0f5a60..ffc6d7f 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ 

Re: Davinci-linux-open-source Digest, Vol 38, Issue 57

[David Chan]

Jon,
What version of cgtools you are using? Frankly, I think that you are  
trying with an incorrect version cgtools.
And maybe the problem is caused from rootdir as Chris pointed out. To  
avoid this problem try to build you codec server like this( you should  
modify according to the path in you system).:


Just write the simplest config.bld to define the compiler and target  
like this:


var C64P = xdc.useModule('ti.targets.C64P');

C64P.rootDir=/home/armdsp/dvsdk_1_40_02_33/cg6x_6_0_21;
C64P.platform = ti.platforms.evmDM6446;

Build.targets = [
C64P,
];

Then set XDCPATH like below:
#!/bin/sh
DVSDK_INSTALL_DIR=${HOME}/dvsdk

BIOS_INSTALL_DIR=${DVSDK_INSTALL_DIR}/bios_5_33_03

CEUTILS_INSTALL_DIR=${DVSDK_INSTALL_DIR}/ceutils_1_06

XDC_INSTALL_DIR=${DVSDK_INSTALL_DIR}/xdc_3_10_03

CE_INSTALL_DIR=${DVSDK_INSTALL_DIR}/codec_engine_2_21

LINK_INSTALL_DIR=${DVSDK_INSTALL_DIR}/dsplink_1_60

FC_INSTALL_DIR=${DVSDK_INSTALL_DIR}/framework_components_2_21

XDAIS_INSTALL_DIR=${DVSDK_INSTALL_DIR}/xdais_6_21

CMEM_INSTALL_DIR=${DVSDK_INSTALL_DIR}/linuxutils_2_21

CODECS_INSTALL_DIR=${DVSDK_INSTALL_DIR}/dm6446_codecs_2_0

BIOSUTILS_INSTALL_DIR=${DVSDK_INSTALL_DIR}/biosutils_1_01_02

#Setlocationofxdcexecutable
XDC=${XDC_INSTALL_DIR}/xdc
XS=${XDC_INSTALL_DIR}/xs

#SetXDCPATHtocontainnecessaryrepositories.
XDCPATH=${CEUTILS_INSTALL_DIR}/packages;${CODECS_INSTALL_DIR}/ 
packages;${XDAIS_INSTALL_DIR}/packages;${FC_INSTALL_DIR}/packages;$ 
{FC_INSTALL_DIR}/fctools/packages;${BIOS_INSTALL_DIR}/packages;$ 
{CMEM_INSTALL_DIR}/packages;${LINK_INSTALL_DIR}/packages;$ 
{CE_INSTALL_DIR}/packages;${BIOSUTILS_INSTALL_DIR}/packages



export XDC
export XDCPATH
export XS

Then compile your server like this:

$XDC -PD .

David Chan (also known as BlackSword.David)

On Feb 12, 2009, at 2:00 AM, davinci-linux-open-source-requ...@linux.davincidsp.com 
 wrote:



Message: 2
Date: Wed, 11 Feb 2009 11:09:52 -0600
From: Ring, Chris cr...@ti.com
Subject: RE: Error build codec servers in DM6446: incompatible use of
taget
To: Jon Arr?spide j...@gti.ssr.upm.es,
davinci-linux-open-source@linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Message-ID:
92cdd168d1e81f4f9d3839dc45903fc644b58...@dlee03.ent.ti.com
Content-Type: text/plain; charset=iso-8859-1

Double-check that your config.bld/user.bld assignment of the C64P  
target's .rootdir is valid.


http://rtsc.eclipse.org/docs-tip/Trouble_Shooting#Configuration_fails_with_an_.22incompatible_use_of_the_target_22_error

Chris


From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com 
] On Behalf Of Jon Arróspide

Sent: Wednesday, February 11, 2009 7:28 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Error build codec servers in DM6446: incompatible use of  
taget


Hello all,

I'm trying to build a codec server in DM6446. However, even if I try  
to build an example server (video_copy) I'm getting the following  
error:


js: /opt/dvevm_1_10/xdctools_1_21/packages/xdc/cfg/cfg.js, line  
143: exception from uncaught _javascript_ throw: Error: incompatible  
use of the target 'ti.targets.C64P', imported version [],  
ti.targets.rts6000 was built using version [1,0,5.2,0,4],  
ti.sdo.ce.trace was built using version [1,0,6.0,3],  
ti.sdo.ce.osal.alg was built using version [1,0,6.0,3],  
ti.bios.utils was built using version [1,0,6.0,3], ti.bios was built  
using version [1,0,6.0,3], ti.rtdx was built using version  
[1,0,6.0,3], ti.sdo.ce.osal was built using version [1,0,6.0,3],  
ti.sdo.fc.dskt2 was built using version [1,0,6.0,3], ti.sdo.fc.dman3  
was built using version [1,0,6.0,3], ti.sdo.fc.acpy3 was built using  
version [1,0,6.0,3], ti.sdo.ce.bioslog was built using version  
[1,0,6.0,3], ti.sdo.ce.node was built using version [1,0,6.0,3],  
ti.sdo.ce was built using version [1,0,6.0,3], ti.sdo.ce.video was  
built using version [1,0,6.0,3], codecs.viddec_copy was built using  
version [1,0,6.0,3], codecs.videnc_c

opy was built using version [1,0,6.0,3]
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Error 1
gmake: *** Deleting file `package/cfg/video_copy_x64Pcfg_c.c'
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file  
`package/cfg/video_copy_x64Pcfg.cmd'
gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file  
`package/cfg/video_copy_x64Pcfg.s62'

make: *** [all] Error 2

Has anybody encountered this problem? Do I need to download some  
upgraded (or downgraded) version of a library/file?

Thank you in advance,

Jon


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Davinci-linux-open-source Digest, Vol 38, Issue 60

[David Chan]

Hi Weixin,

For the experience of using DM6446, I think ecodedecode demo is  
release without audio. The one have audio should be decode.

Please try decode.

David Chan (also known as BlackSword.David)


On Feb 12, 2009, at 8:06 AM, davinci-linux-open-source-requ...@linux.davincidsp.com 
 wrote:



Message: 5
Date: Wed, 11 Feb 2009 16:02:02 -0800 (PST)
From: weixin Li weixinl...@yahoo.com
Subject: DM355 DVSDK's audio
To: davinci-linux-open-source@linux.davincidsp.com
Message-ID: 74096.67426...@web56301.mail.re3.yahoo.com
Content-Type: text/plain; charset=iso-8859-1

Hi,

I am playing DM355 EVM's DVSDK out-of-box demo program. In  
encodedecode demo, I can get video playing on the screen but can't  
get audio on. Is there anybody know why and how to turn audio on?


Thanks,
Weixin


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 4/9] musb_host: fix endpoint_disable() method (take 2)

[David Brownell]

On Wednesday 11 February 2009, Sergei Shtylyov wrote:
 
    Sigh... it will spoil the state of another, curently active endpoint, 
 of course.

What do you mean by spoil then?  Make it match the current
hardware state isn't exactly troublesome; it's not consulted
except when setting up new transfers, and it's saved again
after each URB.  In fact that save state isn't expected to be
valid unless there's no I/O active.



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Davinci-linux-open-source Digest, Vol 38, Issue 60

[weixin Li]

Hi David,
 
Thanks for your input. For the decode, the audio output is decoded from existed 
audio file, not from realtime input. Is there any way that DM355 can process 
audio input realtime?
 
Thanks a lot,
Weixin

--- On Wed, 2/11/09, David Chan blacksword.da...@gmail.com wrote:

From: David Chan blacksword.da...@gmail.com
Subject: Re: Davinci-linux-open-source Digest, Vol 38, Issue 60
To: davinci-linux-open-source@linux.davincidsp.com
Date: Wednesday, February 11, 2009, 6:21 PM


Hi Weixin,


For the experience of using DM6446, I think ecodedecode demo is release without 
audio. The one have audio should be decode.
Please try decode.


David Chan (also known as BlackSword.David)





On Feb 12, 2009, at 8:06 AM, 
davinci-linux-open-source-requ...@linux.davincidsp.com wrote:

Message: 5
Date: Wed, 11 Feb 2009 16:02:02 -0800 (PST)
From: weixin Li weixinl...@yahoo.com
Subject: DM355 DVSDK's audio
To: davinci-linux-open-sou...@linux.davincidsp.com
Message-ID: 74096.67426...@web56301.mail.re3.yahoo.com
Content-Type: text/plain; charset=iso-8859-1

Hi,
 
I am playing DM355 EVM's DVSDK out-of-box demo program. In encodedecode demo, 
I can get video playing on the screen but can't get audio on. Is there anybody 
know why and how to turn audio on?
 
Thanks,
Weixin
___
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: [PATCH 6/9] musb_host: fix premature PIO transfer end (take 2)

[David Brownell]

On Wednesday 04 February 2009, Sergei Shtylyov wrote:
 Feeding 32-bit length cast down to 'u16' to min() to calculate the FIFO count
 in musb_host_tx() risks sending a short packet prematurely for transfer sizes
 over 64 KB. And although data transfer size shouldn't exceed 65535 bytes for
 the control endpoint, making musb_h_ep0_continue() more robust WRT URBs with
 possibly oversized buffer will not hurt either...
 
 Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com

Acked-by: David Brownell dbrown...@users.sourceforge.net

OK for 2.6.29-rc ... maybe a bit marginal, unless someone
has specifically observed this.  But I hope the merge criteria
aren't that tight yet; this would prevent various intermittent
and poorly-reproducible flakiness.

 
 
 ---
 Only whitespace changes. The patch is against the recent Linus' kernel...
 
  drivers/usb/musb/musb_host.c |   14 +++---
  1 files changed, 7 insertions(+), 7 deletions(-)
 
 Index: linux-2.6/drivers/usb/musb/musb_host.c
 ===
 --- linux-2.6.orig/drivers/usb/musb/musb_host.c
 +++ linux-2.6/drivers/usb/musb/musb_host.c
 @@ -936,8 +936,8 @@ static bool musb_h_ep0_continue(struct m
   switch (musb-ep0_stage) {
   case MUSB_EP0_IN:
   fifo_dest = urb-transfer_buffer + urb-actual_length;
 - fifo_count = min(len, ((u16) (urb-transfer_buffer_length
 - - urb-actual_length)));
 + fifo_count = min_t(size_t, len, urb-transfer_buffer_length -
 +urb-actual_length);
   if (fifo_count  len)
   urb-status = -EOVERFLOW;
  
 @@ -970,10 +970,9 @@ static bool musb_h_ep0_continue(struct m
   }
   /* FALLTHROUGH */
   case MUSB_EP0_OUT:
 - fifo_count = min(qh-maxpacket, ((u16)
 - (urb-transfer_buffer_length
 - - urb-actual_length)));
 -
 + fifo_count = min_t(size_t, qh-maxpacket,
 +urb-transfer_buffer_length -
 +urb-actual_length);
   if (fifo_count) {
   fifo_dest = (u8 *) (urb-transfer_buffer
   + urb-actual_length);
 @@ -1303,7 +1302,8 @@ void musb_host_tx(struct musb *musb, u8 
* packets before updating TXCSR ... other docs disagree ...
*/
   /* PIO:  start next packet in this URB */
 - wLength = min(qh-maxpacket, (u16) wLength);
 + if (wLength  qh-maxpacket)
 + wLength = qh-maxpacket;
   musb_write_fifo(hw_ep, wLength, buf);
   qh-segsize = wLength;
  
 
 



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG timeout issue

[Narnakaje, Snehaprabha]

 -Original Message-
 From: David Brownell [mailto:davi...@pacbell.net]
 Sent: Wednesday, February 11, 2009 7:29 PM
 To: Narnakaje, Snehaprabha
 Cc: davinci-linux-open-source@linux.davincidsp.com
 Subject: Re: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG
 timeout issue
 
 On Wednesday 11 February 2009, Narnakaje, Snehaprabha wrote:
 
Ideally spin_lock_irqsave is supposed to disable interrupts
locally. Does it mean GPIO1 interrupt or does it mean dm9000
hardware interrupt.
  
   Neither.  It clears the CPU's IRQ-enable bit ... not the
   GPIO bank 0 IRQ enable, and not the dm9000-internal enable.
  
   While that IRQ is being processed, I seem to recall that the
   bank 0 IRQ is masked in the toplevel DaVinci IRQ controller;
   as well as the CPU's IRQ-enable bit.
  
   Is there maybe a level vs edge triggering issue?
 
  I had tried to change the dm9000 IRQ resource to falling edge
  (instead of rising edge), but that didn't help.
 
 You might try making it use the dedicated GPIO1 IRQ instead
 of going through the GPIO controller.  In that case, specify
 it as a level IRQ (I think).  If that works, it'll indicate
 some kind of problem in the GPIO IRQ chaining.
 
 Thing is, I've never seen those IRQs work.  I think it may
 have had something to do with having the IRQ for that bank
 of GPIOs enabled.  There was never enough incentive to chase
 down whatever problem it was ... at least, for me!

Yes, I have also tried to use the dedicated GPIO1 IRQ (45, instead of 65) and 
no interrupts come to dm9000 driver in this case.

 
 - Dave

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 7/9] musb_host: don't limit interval for low speed devices

[David Brownell]

On Wednesday 04 February 2009, Sergei Shtylyov wrote:
 Remove wrongly applied upper limit on the interrupt transfer interval for the
 low speed devices (not much of an error per se, according to the USB specs)...
 
 Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com

Acked-by: David Brownell dbrown...@users.sourceforge.net

OK for 2.6.29-rc, though as not much of an error
I wouldn't push for it.


 ---
 The patch is against the recent Linus' kernel.
 
  drivers/usb/musb/musb_host.c |   18 ++
  1 files changed, 10 insertions(+), 8 deletions(-)
 
 Index: linux-2.6/drivers/usb/musb/musb_host.c
 ===
 --- linux-2.6.orig/drivers/usb/musb/musb_host.c
 +++ linux-2.6/drivers/usb/musb/musb_host.c
 @@ -1857,19 +1857,21 @@ static int musb_urb_enqueue(
   }
   qh-type_reg = type_reg;
  
 - /* precompute rxinterval/txinterval register */
 - interval = min((u8)16, epd-bInterval); /* log encoding */
 + /* Precompute RXINTERVAL/TXINTERVAL register */
   switch (qh-type) {
   case USB_ENDPOINT_XFER_INT:
 - /* fullspeed uses linear encoding */
 - if (USB_SPEED_FULL == urb-dev-speed) {
 - interval = epd-bInterval;
 - if (!interval)
 - interval = 1;
 + /*
 +  * Full/low speeds use the  linear encoding,
 +  * high speed uses the logarithmic encoding.
 +  */
 + if (urb-dev-speed = USB_SPEED_FULL) {
 + interval = max_t(u8, epd-bInterval, 1);
 + break;
   }
   /* FALLTHROUGH */
   case USB_ENDPOINT_XFER_ISOC:
 - /* iso always uses log encoding */
 + /* ISO always uses logarithmic encoding */
 + interval = min_t(u8, epd-bInterval, 16);
   break;
   default:
   /* REVISIT we actually want to use NAK limits, hinting to the
 
 



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 8/9] musb_host: fix premature Tx URB giveback in DMA mode

[David Brownell]

On Wednesday 04 February 2009, Sergei Shtylyov wrote:
 ---
 This is a new patch in series; it's too against the recent Linus' kernel...
 The code is not exactly trivial but hopefully self-documented, it has been
 successfulyl stress tested with CPPI 3.0 and 4.1 drivers, though still needs
 verification with Inventra DMA...

This looks very interesting, but it looks a bit too complex to
consider acking for 2.6.29, given there's a trivial use PIO
workaround and it's only been tested with one of the three DMA
engines in use.

No other comment yet.  :)

- Dave


  drivers/usb/musb/cppi_dma.c  |   22 
  drivers/usb/musb/musb_host.c |   75 
 ---
  drivers/usb/musb/musbhsdma.c |    7 +---
  3 files changed, 74 insertions(+), 30 deletions(-)



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: Dsplink.dsp?

[Ryan Talbot]

Well, I changed all occurrences of DDR to DDR2 in app.tcf and
app.cfg in my ateme/servers/xavsc_ateme_server directory.  The
undefined symbol _DDR2 error went away, but it still failed to link
with:

/home/rtalbot/dvevm_2_21/cg6x_6_0_16/bin/lnk6x -w -q -u _c_int00 -s -l
link.cmd -q -o xavsc_ateme_server.x64P
package/cfg/xavsc_ateme_server/main.o64P
package/cfg/xavsc_ateme_server_x64P.o64P
package/cfg/xavsc_ateme_server_x64Pcfg.o64P
package/cfg/xavsc_ateme_server_x64Pcfg_c.o64P
package/cfg/xavsc_ateme_server_x64P.xdl  -c -m
package/cfg//xavsc_ateme_server.x64P.map -l
/home/rtalbot/dvevm_2_21/cg6x_6_0_16/lib/rts64plus.lib
 warning: can't find a memory area named 'DDR' on page 0 for
allocation of
'.text:avsc_init'
   error: can't find any memory areas for allocation of
'.text:avsc_init'
   error: can't allocate '.text:avsc_init' into 'DDR' (page 0)
 warning: can't find a memory area named 'DDR' on page 0 for
allocation of
'.text:avsc_pic'
   error: can't find any memory areas for allocation of
'.text:avsc_pic'
   error: can't allocate '.text:avsc_pic' into 'DDR' (page 0)
   error: errors in input - xavsc_ateme_server.x64P not built
gmake: *** [xavsc_ateme_server.x64P] Error 1

Was there a higher-level .tcf and .cfg file I needed to modify?  It
seems like not all of the components got the memo...

Thanks again for your help, guys,
Ryan

 -Original Message-
 From: David Chan [mailto:blacksword.da...@gmail.com] 
 Sent: Wednesday, February 11, 2009 8:27 AM
 To: Griffis, Brad
 Cc: Ryan Talbot; davinci-linux-open-source@linux.davincidsp.com
 Subject: Re: Dsplink.dsp?
 
 Hi guys,
 
 Don't guess anymore. I've built my own codec package tree and 
 codec server tree. DDR is not the problem. From DSPLINK1.40. 
 DDR2 to is used to take the place of DDR. Just rename the 
 section DDR to DDR2. and modify the correspond to DDR in the 
 .cfg file. It will be compiled without any problem. But When 
 the server run your Linux system will be crashed. I've check 
 with TI, the problem should be from the codec himself. Codec 
 is not compatible to Xdais 6.20 or later, hence imcompatible 
 to dsplink1.6.  They send me a mail, that they've send me the 
 new codec. But problem now is I can't track my package with Fedex.
 Wish I can got them soon.
 On Feb 11, 2009, at 9:15 PM, Griffis, Brad wrote:
 
  I've run into similar issues in the past.  In my case the error 
  originated in the tcf file for the DSP.  There seems to be a little 
  bit of inconsistency in the naming of the external memory.  I have 
  seen some processors where it's called DDR and other processors 
  where it's called DDR2.
 
  -Original Message-
  From: Ryan Talbot [mailto:rtal...@vtti.vt.edu]
  Sent: Wednesday, February 11, 2009 3:57 AM
  To: David Chan
  Cc: Griffis, Brad; davinci-linux-open-source@linux.davincidsp.com
  Subject: RE: Dsplink.dsp?
 
  Hey guys,
 
  I'm now getting a linker error while building the server.  It says 
  that
  _DDR2 is an undefined symbol, coming from dsplink.lib.  I 
 guess this 
  is because I am now using DSPLink 1.60 instead of 1.30, 
 but I can't 
  find any information on this _DDR2 symbol.  Does anybody 
 know what it 
  means or what it should be?
 
  I also could not find the BIOSUtils package anywhere as a 
 standalone 
  download.  I ended up creating a symbolic 'bios' link that 
 resides in 
  codec_engine_2_21/packages/ti that points to 
  codec_engine_2_21/cetools/packages/ti/bios, because otherwise the 
  compilation would fail saying that it couldn't find the package 
  ti.bios.utils.
 
  You guys have been a great help, thanks!
  Ryan
 
  -Original Message-
  From: David Chan [mailto:blacksword.da...@gmail.com]
  Sent: Tuesday, February 10, 2009 9:04 AM
  To: Ryan Talbot
  Cc: Griffis, Brad; davinci-linux-open-source@linux.davincidsp.com
  Subject: Re: Dsplink.dsp?
 
  Ryan,
 
  It's seems that you are not using the DVSDK2.0EA edition. I think 
  that you will meet another roadblock as I have meet.
 
  If the codec is not developed by your own team, you will 
 find that 
  the Codec is not compatible the dsplink 1.50 or later.
  (Video_copy can run, but the codec server from current 
 codecs will 
  crashed the kernel! This is why my personal release of
  CE2.21 based on my toolchain is delayed)
 
  Just got the mail from TI, that new codecs are Fedexed to me.
  But until now, I don't know where are them. Trying tracking them 
  now!
 
  The best now seems to be dsplink1.4 with mv50 (or my
  toolchain) and new kernel .
 
  David
  On Feb 10, 2009, at 2:08 PM, Ryan Talbot wrote:
 
  Thanks, Brad, that seems to have cleared that roadblock. 
  I hadn't 
  noticed that difference between the two releases...
  downloading each
  component separately really is proving to be a pain.
 
  David, thanks again for your input earlier; I was in the 
 process of 
  implementing it when Brad's solution showed up in my inbox
  and did the
  trick.
 
  Ryan
 
  -Original 

Re: Dsplink.dsp?

[Brian G Rhodes]

Ryan Talbot wrote:

Well, I changed all occurrences of DDR to DDR2 in app.tcf and
app.cfg in my ateme/servers/xavsc_ateme_server directory.  The
undefined symbol _DDR2 error went away, but it still failed to link
with:

/home/rtalbot/dvevm_2_21/cg6x_6_0_16/bin/lnk6x -w -q -u _c_int00 -s -l
link.cmd -q -o xavsc_ateme_server.x64P
package/cfg/xavsc_ateme_server/main.o64P
package/cfg/xavsc_ateme_server_x64P.o64P
package/cfg/xavsc_ateme_server_x64Pcfg.o64P
package/cfg/xavsc_ateme_server_x64Pcfg_c.o64P
package/cfg/xavsc_ateme_server_x64P.xdl  -c -m
package/cfg//xavsc_ateme_server.x64P.map -l
/home/rtalbot/dvevm_2_21/cg6x_6_0_16/lib/rts64plus.lib
  

warning: can't find a memory area named 'DDR' on page 0 for
  

allocation of
'.text:avsc_init'
  

  error: can't find any memory areas for allocation of
  

'.text:avsc_init'
  

  error: can't allocate '.text:avsc_init' into 'DDR' (page 0)
warning: can't find a memory area named 'DDR' on page 0 for
  

allocation of
'.text:avsc_pic'
  

  error: can't find any memory areas for allocation of
  

'.text:avsc_pic'
  

  error: can't allocate '.text:avsc_pic' into 'DDR' (page 0)
  error: errors in input - xavsc_ateme_server.x64P not built
  

gmake: *** [xavsc_ateme_server.x64P] Error 1

Was there a higher-level .tcf and .cfg file I needed to modify?  It
seems like not all of the components got the memo...

Thanks again for your help, guys,
Ryan

  


Does your server config have any of those algorithm sections in 'DDR'?  
If it's not defined the linker may be trying to automatically use DDR.  
Check if the failing sections are defined in your server config.  .text 
is one of the pre-defined sections which the linker (if not defined in 
the server config) will try to automatically place.


My basic understanding is that the tconf specifies the canonical names 
for the memory addresses which the config assigns sections to.  The 
codec can place code and data in those sections.  Does the linker map 
file get generated even though linking fails?  If so, that may shed some 
light on anything you may have missed.



-Original Message-
From: David Chan [mailto:blacksword.da...@gmail.com] 
Sent: Wednesday, February 11, 2009 8:27 AM

To: Griffis, Brad
Cc: Ryan Talbot; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Dsplink.dsp?

Hi guys,

Don't guess anymore. I've built my own codec package tree and 
codec server tree. DDR is not the problem. From DSPLINK1.40. 
DDR2 to is used to take the place of DDR. Just rename the 
section DDR to DDR2. and modify the correspond to DDR in the 
.cfg file. It will be compiled without any problem. But When 
the server run your Linux system will be crashed. I've check 
with TI, the problem should be from the codec himself. Codec 
is not compatible to Xdais 6.20 or later, hence imcompatible 
to dsplink1.6.  They send me a mail, that they've send me the 
new codec. But problem now is I can't track my package with Fedex.

Wish I can got them soon.
On Feb 11, 2009, at 9:15 PM, Griffis, Brad wrote:


I've run into similar issues in the past.  In my case the error 
originated in the tcf file for the DSP.  There seems to be a little 
bit of inconsistency in the naming of the external memory.  I have 
seen some processors where it's called DDR and other processors 
where it's called DDR2.


  

-Original Message-
From: Ryan Talbot [mailto:rtal...@vtti.vt.edu]
Sent: Wednesday, February 11, 2009 3:57 AM
To: David Chan
Cc: Griffis, Brad; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Dsplink.dsp?

Hey guys,

I'm now getting a linker error while building the server.  It says 
that
_DDR2 is an undefined symbol, coming from dsplink.lib.  I 

guess this 

is because I am now using DSPLink 1.60 instead of 1.30, 

but I can't 

find any information on this _DDR2 symbol.  Does anybody 

know what it 


means or what it should be?

I also could not find the BIOSUtils package anywhere as a 

standalone 

download.  I ended up creating a symbolic 'bios' link that 

resides in 

codec_engine_2_21/packages/ti that points to 
codec_engine_2_21/cetools/packages/ti/bios, because otherwise the 
compilation would fail saying that it couldn't find the package 
ti.bios.utils.


You guys have been a great help, thanks!
Ryan



-Original Message-
From: David Chan [mailto:blacksword.da...@gmail.com]
Sent: Tuesday, February 10, 2009 9:04 AM
To: Ryan Talbot
Cc: Griffis, Brad; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Dsplink.dsp?

Ryan,

It's seems that you are not using the DVSDK2.0EA edition. I think 
that you will meet another roadblock as I have meet.


If the codec is not developed by your own team, you will 
  
find that 


the Codec is not compatible the dsplink 1.50 or later.
(Video_copy can run, but the codec server from current 
  
codecs will 


crashed 

Reg: Cross compiled ffplay on dvevm dm6446, problems..crashes..?

[Ragas sag]

Hi Xperts,

I cross compiled ffmpeg sources to generate ffplay binary. And target is
DVEVM DM6446..armv5te . My configuration settings are:

./configure --enable-cross-compile --arch=arm --logfile=config.log
--cpu=armv5te
--cross-prefix=/opt/mv_pro_4.0/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-
--cc=arm_v5t_le-gcc --enable-ffplay
--extra-cflags=-I/home/sagar/temp/ffmpeg/ffmpeg/SDL-1.2.13/sdl_arm/usr/local/include/SDL/
--extra-ldflags=-L/home/sagar/temp/ffmpeg/ffmpeg/SDL-1.2.13/sdl_arm/usr/local/lib
--shlibdir=/home/sagar/temp/ffmpeg/ffmpeg/SDL-1.2.13/sdl_arm/usr/local/lib
--extra-libs=-L/home/sagar/temp/ffmpeg/ffmpeg/SDL-1.2.13/sdl_arm/usr/local/lib
--enable-swscale --enable-postproc --enable-gpl --disable-armvfp

I am able to genetrate ffplay binary, and when i test the binary on the
DVEVM board, the file starts playing and betefore the file ends, i get the
collowing kernal dump messages as below.

My question's are;
1) Am i making a mistake in my configuration settings?
2) If not, than any idead about why this below mentioned crash is happening?
3) And if at all memory leaks in ffmpeg, how do i find/fix that?

# FFplay version SVN-r17153, Copyright (c) 2003-2009 Fabrice Bellard, et al.
configuration: --enable-cross-compile --arch=arm --logfile=config.log
--cpu=armv5te
--cross-prefix=/opt/mv_pro_4.0/montavista/pro/devkit/arm/v5t_le/bin/arp
libavutil 49.14. 0 / 49.14. 0
libavcodec 52.11. 0 / 52.11. 0
libavformat 52.26. 0 / 52.26. 0
libavdevice 52. 1. 0 / 52. 1. 0
libswscale 0. 6. 1 / 0. 6. 1
libpostproc 51. 2. 0 / 51. 2. 0
built on Feb 12 2009 12:23:15, gcc: 3.4.3 (MontaVista 3.4.3-25.0.30.0501131
2005-07-23)
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1600 1200
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1408 1056
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1280 1024
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1152 864
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1024 768
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 960
720
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 800
600
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 768
576
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 720
576
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1600 1200
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1408 1056
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1280 1024
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1152 864
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1024 768
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 960
720
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 800
600
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 768
576
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 720
576
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1600 1200
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1408 1056
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1280 1024
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1152 864
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1024 768
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 960
720
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 800
600
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 768
576
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 720
576
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1600 1200
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1408 1056
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1280 1024
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1152 864
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0
1024 768
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 960
720
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 800
600
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 768
576
davincifb davincifb.0: davincifb_check_var :within_vid0_limits fail. 0 0 720
576
oom-killer: gfp_mask=0x1d2
DMA per-cpu:
cpu 0 hot: low 14, high 42, batch 7
cpu 0 cold: low 0, high 14, batch 7
Normal per-cpu: empty
HighMem per-cpu: empty
Free pages: 1380kB (0kB HighMem)
Active:22362 inactive:588 dirty:0 writeback:0 unstable:0 free:345 slab:2160
mapped:22179 pagetables:79
DMA free:1380kB min:1400kB low:1748kB high:2100kB active:89448kB
inactive:2352kB present:122880kB 

Re: Dsplink.dsp?

[David Chan]

Ryan,

What's your new failure log?

David
On Feb 12, 2009, at 1:57 PM, Ryan Talbot wrote:


Well, I changed all occurrences of DDR to DDR2 in app.tcf and
app.cfg in my ateme/servers/xavsc_ateme_server directory.  The
undefined symbol _DDR2 error went away, but it still failed to link
with:

/home/rtalbot/dvevm_2_21/cg6x_6_0_16/bin/lnk6x -w -q -u _c_int00 -s -l
link.cmd -q -o xavsc_ateme_server.x64P
package/cfg/xavsc_ateme_server/main.o64P
package/cfg/xavsc_ateme_server_x64P.o64P
package/cfg/xavsc_ateme_server_x64Pcfg.o64P
package/cfg/xavsc_ateme_server_x64Pcfg_c.o64P
package/cfg/xavsc_ateme_server_x64P.xdl  -c -m
package/cfg//xavsc_ateme_server.x64P.map -l
/home/rtalbot/dvevm_2_21/cg6x_6_0_16/lib/rts64plus.lib

warning: can't find a memory area named 'DDR' on page 0 for

allocation of
   '.text:avsc_init'

 error: can't find any memory areas for allocation of

'.text:avsc_init'

 error: can't allocate '.text:avsc_init' into 'DDR' (page 0)
warning: can't find a memory area named 'DDR' on page 0 for

allocation of
   '.text:avsc_pic'

 error: can't find any memory areas for allocation of

'.text:avsc_pic'

 error: can't allocate '.text:avsc_pic' into 'DDR' (page 0)
 error: errors in input - xavsc_ateme_server.x64P not built

gmake: *** [xavsc_ateme_server.x64P] Error 1

Was there a higher-level .tcf and .cfg file I needed to modify?  It
seems like not all of the components got the memo...

Thanks again for your help, guys,
Ryan


-Original Message-
From: David Chan [mailto:blacksword.da...@gmail.com]
Sent: Wednesday, February 11, 2009 8:27 AM
To: Griffis, Brad
Cc: Ryan Talbot; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Dsplink.dsp?

Hi guys,

Don't guess anymore. I've built my own codec package tree and
codec server tree. DDR is not the problem. From DSPLINK1.40.
DDR2 to is used to take the place of DDR. Just rename the
section DDR to DDR2. and modify the correspond to DDR in the
.cfg file. It will be compiled without any problem. But When
the server run your Linux system will be crashed. I've check
with TI, the problem should be from the codec himself. Codec
is not compatible to Xdais 6.20 or later, hence imcompatible
to dsplink1.6.  They send me a mail, that they've send me the
new codec. But problem now is I can't track my package with Fedex.
Wish I can got them soon.
On Feb 11, 2009, at 9:15 PM, Griffis, Brad wrote:


I've run into similar issues in the past.  In my case the error
originated in the tcf file for the DSP.  There seems to be a little
bit of inconsistency in the naming of the external memory.  I have
seen some processors where it's called DDR and other processors
where it's called DDR2.


-Original Message-
From: Ryan Talbot [mailto:rtal...@vtti.vt.edu]
Sent: Wednesday, February 11, 2009 3:57 AM
To: David Chan
Cc: Griffis, Brad; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Dsplink.dsp?

Hey guys,

I'm now getting a linker error while building the server.  It says
that
_DDR2 is an undefined symbol, coming from dsplink.lib.  I

guess this

is because I am now using DSPLink 1.60 instead of 1.30,

but I can't

find any information on this _DDR2 symbol.  Does anybody

know what it

means or what it should be?

I also could not find the BIOSUtils package anywhere as a

standalone

download.  I ended up creating a symbolic 'bios' link that

resides in

codec_engine_2_21/packages/ti that points to
codec_engine_2_21/cetools/packages/ti/bios, because otherwise the
compilation would fail saying that it couldn't find the package
ti.bios.utils.

You guys have been a great help, thanks!
Ryan


-Original Message-
From: David Chan [mailto:blacksword.da...@gmail.com]
Sent: Tuesday, February 10, 2009 9:04 AM
To: Ryan Talbot
Cc: Griffis, Brad; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Dsplink.dsp?

Ryan,

It's seems that you are not using the DVSDK2.0EA edition. I think
that you will meet another roadblock as I have meet.

If the codec is not developed by your own team, you will

find that

the Codec is not compatible the dsplink 1.50 or later.
(Video_copy can run, but the codec server from current

codecs will

crashed the kernel! This is why my personal release of
CE2.21 based on my toolchain is delayed)

Just got the mail from TI, that new codecs are Fedexed to me.
But until now, I don't know where are them. Trying tracking them
now!

The best now seems to be dsplink1.4 with mv50 (or my
toolchain) and new kernel .

David
On Feb 10, 2009, at 2:08 PM, Ryan Talbot wrote:


Thanks, Brad, that seems to have cleared that roadblock.

I hadn't

noticed that difference between the two releases...

downloading each

component separately really is proving to be a pain.

David, thanks again for your input earlier; I was in the

process of

implementing it when Brad's solution showed up in my inbox

and did the

trick.

Ryan


-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com

Re: Reg: Cross compiled ffplay on dvevm dm6446, problems..crashes..?

[Vladimir Pantelic]

Ragas sag wrote:

Hi Xperts,

I cross compiled ffmpeg sources to generate ffplay binary. And target is 


I am able to genetrate ffplay binary, and when i test the binary on the 
DVEVM board, the file starts playing and betefore the file ends, i get 
the collowing kernal dump messages as below. 


My question's are;
1) Am i making a mistake in my configuration settings?
2) If not, than any idead about why this below mentioned crash is happening?


ffplay is crashing because it is using to much memory, the kernel out-of-memory 
killer then kills it.


3) And if at all memory leaks in ffmpeg, how do i find/fix that?


ffplay might not leak memory, it might just use more than you have.

ffplay is a quite well debugged SW and I doubt that it leaks memory just like that, but maybe there something that makes 
it leak on the dm6446.


how much memory do you have before starting ffplay (type free)?



___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source