[Linux-Xtensa] Re: Audio Driver - applied your git patch, I'm looking into building your config on an LX200...

Piet Delaney pdelaney at tensilica.com
Wed Sep 15 21:24:30 PDT 2010

Piet Delaney wrote:

Hi Truby:

> truby.zhuang wrote:
>> Hi,piet:
>> Thx for your reply.
>> *1. About the git*
>> Consider that I do not know If it is ok to push my codes to the git you 
>> give me last time,
>> I just make a patch which include dirver code of 507T only;
>> *I have send a tar package to Twang a long time ago*, which includes the 
>> other part of codes
>> (dsp_code and test routine).
> Looks like I didn't have the git repo set up quite right.
> I made a new copy of xtensa-2.6.29-smp and seem to have
> fixed the problem. The repo is as before owned by you
> and Chipbanks. I pushed your patch and since have made
> a small asm fix to allow it to work a bit on the DC233 I/O port.
> Your test program runs into a memory allocation problem when
> I start it on the target.
> ------------------------------
> [root at DC_C_233L test]# ./dsp_test
> open dsp dev
> init oss device:3 ok
> open audio dsp dev
> --------------------------------
> I'm Wondering if you changed how memory is allocated. Wondering if my change from allocating
> memory to ZONE_NORMAL instead of ZONE_DMA is completely correct:
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
> (gdb) up
> #1  0xd00498c8 in __out_of_memory (gfp_mask=209, order=0) at mm/oom_kill.c:542
> (gdb) bt
> #0  oom_kill_process (p=0xd39c49a0, gfp_mask=209, order=0, points=102, mem=0x0, message=0xd02279ec "Out of memory") at mm/oom_kill.c:391
> #1  0xd00498c8 in __out_of_memory (gfp_mask=209, order=0) at mm/oom_kill.c:542
> #2  0xd00499f9 in out_of_memory (zonelist=0xd02b6db8, gfp_mask=209, order=0) at mm/oom_kill.c:626
> #3  0xd004be8e in __alloc_pages_internal (gfp_mask=209, order=0, zonelist=0xd02b6db8, nodemask=0x0) at mm/page_alloc.c:1625
> #4  0xd004c0c8 in __alloc_pages (gfp_mask=209, order=0, zonelist=0xd02b6db8) at include/linux/gfp.h:178
> #5  0xd004c072 in alloc_pages_node (nid=0, gfp_mask=209, order=0) at include/linux/gfp.h:199
> #6  0xd004c014 in __get_free_pages (gfp_mask=209, order=0) at mm/page_alloc.c:1681
> #7  0xd0006604 in dma_alloc_coherent (dev=0x0, size=32, handle=0xd39cbc70, flag=209) at arch/xtensa/kernel/pci-dma.c:44
> #8  0xd017a9be in cbm60xx_dsp_open (inode=0xd3454a80, file=0xd3a03200) at drivers/media/audio/cbm60xx_dsp.c:368
> #9  0xd007d7f8 in chrdev_open (inode=0xd3454a80, filp=0xd3a03200) at fs/char_dev.c:396
> #10 0xd0078bc9 in __dentry_open (dentry=0xd3453c90, mnt=0xd380c388, flags=2, f=0xd3a03200, open=0xd007d6d0 <chrdev_open>, cred=0xd39fd2e0) at fs/open.c:839
> #11 0xd0078f79 in nameidata_to_filp (nd=0xd39cbde4, flags=2) at fs/open.c:942
> #12 0xd0085156 in do_filp_open (dfd=-100, pathname=0xd3a0b000 "/dev/adsp", open_flag=2, mode=0) at fs/namei.c:1779
> #13 0xd007918c in do_sys_open (dfd=-100, filename=0x400a00 "/dev/adsp", flags=2, mode=0) at fs/open.c:1035
> #14 0xd007926c in sys_open (filename=0x400a00 "/dev/adsp", flags=2, mode=0) at fs/open.c:1056
> #15 0xd0002c64 in system_call () at arch/xtensa/kernel/entry.S:2103
> #16 0xd00023a5 in _user_exception () at arch/xtensa/kernel/entry.S:321
> #17 0xc0000001 in ?? ()
> Cannot access memory at address 0xc0000001
> (gdb)
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
> I didcussed this change with Christian but never had an opportunity to try it with DMA devices:
> ................................................................................................
> 					arch/xtensa/mm/init.c
> ................................................................................................
> 170 void __init zones_init(void)
> 171 {
> 172         unsigned long zones_size[MAX_NR_ZONES];
> 173         int i;
> 174
> 175         for (i = 0; i < MAX_NR_ZONES; i++)
> 176                 zones_size[i] = 0;
> 177
> 178 #if 0
> 179         /* All pages are DMA-able, so we put them all in the DMA zone. */
> 180         zones_size[ZONE_DMA] = max_low_pfn - ARCH_PFN_OFFSET;
> 181 #else
> 182         /*
> 183          * Xtensa doesn't need a ZONE_DMA. I386 needs it because
> 184          * ISA cards can only access the lower 16MB of memory.
> 185          *
> 186          * REMIND:
> 187          *    ARM enables CONFIG_ZONE_DMA in all of their default configs.
> 188          *    Why?
> 189          */
> 190         zones_size[ZONE_NORMAL] = max_low_pfn - ARCH_PFN_OFFSET;
> 191 #endif
> 192
> 193 #ifdef CONFIG_HIGHMEM
> 194         zones_size[ZONE_HIGHMEM] = max_pfn - max_low_pfn;
> 195 #endif
> 196
> 197         free_area_init_node(0, zones_size, ARCH_PFN_OFFSET, NULL);
> 198 }
> ................................................................................................
> I'm going to try backing it out and see if it fixes this problem.
It did, so I'll back that 'fix' out.

This time I got further. I hit the problem with the allocation with
premption held but unfortunately didn't have a breakpoint enabled to
catch it. Next time.
[root at DC_C_233L ~]# mount /home/default
[root at DC_C_233L ~]# cd /home/default
[root at DC_C_233L default]# ls
Audio_Tests/                    hifitest/
Chipbanks/                      mplayer_packages/
HrTimers/                       save_root_files*
LTP_Test/                       saved_root_files/
Music/                          saved_root_files.tar
SSH_Keys                        saved_root_files.tar.prev
Tests/                          saved_root_files.tar.prev.prev
crash-utility/                  swap/
[root at DC_C_233L default]# cd Chipbanks/
[root at DC_C_233L Chipbanks]# ls
[root at DC_C_233L Chipbanks]# cd test
[root at DC_C_233L test]# ls
Makefile            dsp_test*           kungfu_mp3.h
cbm60xx_dsp.h       dsp_test.c          mp3_stream.h
cbm60xx_dsp.h.Orig  dsp_test.c.Orig
[root at DC_C_233L test]# ./dsp_test
open dsp dev
init oss device:3 ok

open audio dsp dev

request chan

Init chan
BUG: sleeping function called from invalid context at kernel/rwsem.c:21
in_atomic(): 0, irqs_disabled(): 3, pid: 80, name: dsp_test

Stack: 00000018 b07f3732 0000000f ffffffff 00000001 00000014 66666666 00003636
        d3a00000 00000002 00000050 00000000 b07b5fdd 00000009 d03be020 d3a037b0
        90044162 d3a03850 000026b8 00000020 b0a71318 00000000 00000020 00000000
Call Trace:

Then I hit an interesting citation where in sudio_dsp_decode() it's
using a reasonable pointer in chan (0xd389aee8) but in the function below
it, SendPlayChanMail(), the value appears to be NULL, yet it just executed
code above the preparation to call SendMail() that uses the pointer and
didn't experience an exception. The exception is caused by using an address 0x8.

My guess is that you memcpy() to the local variable 'data' on the stack was
bogus and clobbered the formal on the stack. 'data' is of type 'mailDataT'
but the memcpy is of sizeof(streamT). Looks like a bug. Your copying 16
bytes into a local variable that's only 4 bytes long. Right?

If your not using xt-gdb already I strongly encourage it. It's worth
the short term investment in time. Pays off in spades. Exchanging
information about your problems with git and xt-gdb is the ticket
to our providing low cost support and maximizing the success of your

Could you update the chipbanks git repo with the bug fix and I'll
pull it and continue.

In the mean time I'll work on a DC233 V3 MMU bug fix for Christian
and making the configs for your cores for a LX200 implementation in
case I can get some help from Marc and Steve to add a little RTL
to connect the TIE queues together.

Let me know if I should help you with the:

	BUG: sleeping function called from invalid context at kernel/rwsem.c:21

I suspect it better for you to use Marc and I for more difficult issues.

Looks like we are making good progress. Hope to see your fix(s) soon.

We have a presentation at 11:00am tomorrow. Perhaps I
shouldn't work so late this evening and instead pop a few
sleeping pills, and try to attend it.


> -piet
>> I agree that we use the same git(*xtensa-2.6.29-smp-chipsbank.git*), I 
>> am polling it down now,
>> and commit all codes in drivers/media/audio.
>> Since it will take hours to clone the git, *Attached with the previous 
>> package*.
>> audio/test/dsp_test.c is the test routine you need.
>> Would you please test the routines in this package first.
>> The dsp_code and test codes are the same as this package.
>> *2. How to use the mp3_dec lib*
>> the dsp code should be set up as a Xplorer project, currently, I do not 
>> write a Makefile manual,
>> and just simply link the mp3_dec lib to dsp_code binary.
>>  Files in dsp_code dir is the dsp codes we developed, create a project with
>>       Xplorer, while the rlt330lsp is the lsp and set up the project 
>> setting as follow:
>>       include path:
>>       $(PROJECT_HOME)/inc,$(PROJECT_HOME)/base_vns
>>  Defines:
>>       RTLSIM        : set up running environment as RTL simulation 
>> (necesaary!)
>>       DEBUG_LOG  : enable print log information (if you want to see 
>> debug info)
>>  Custom LSP:
>>       $(PROJECT_HOME)/rtl330lsp
>>  Linker Flags:
>>       -lc  *$(PROJECT_HOME)/lib/xa_mp3_dec.a* -mlsp=$(PROJECT_HOME)/rtl330ls
>>  Please let me konw if you get any confuse about our driver.
>> -------------------------------------------------------
>> With Regards,
>> Truby.Zong 
>>  庄厝边
>> -------------------------------------------------------
>> 深圳芯邦科技股份有限公司
>> Chipsbank Microelectronic LTD.
>> 地址:深圳市高新区科技中二路软件园12号楼7层
>>         No.701-712,Building No.12,Keji Central Road 2,
>>         Software Park,High-tech Industrial Park,Shenzhen,
>>         P.R. China 518057
>> Tel: +86-755-86169650  ext 831  Fax: +86-755-86169690
>> WebSite:www.chipsbank.com <http://www.chipsbank.com/>
>> Email:    truby.zhuang at chipsbank.com <mailto:truby.zhuang at chipsbank.com>
>> ------------------------------------------------------------------------
>> *发件人:* Piet Delaney
>> *发送时间:* 2010-09-15  13:54:12
>> *收件人:* truby.zhuang at chipsbank.com
>> *抄送:* linux-xtensa at linux-xtensa.org; MarcGauthier; Tong Wang; Sarang 
>> Shelke
>> *主题:* Audio Driver - applied your git patch, I'm looking into 
>> buildingyour config on an LX200...
>> Hi Truby:
>> I Applied your patch with 'git apply':
>> ----------------------------------------------------------------------------------
>> [piet at pdelaney_fc9 xtensa-2.6.29-smp]$ git apply ../git_patch_chipsbank_10_09_08
>> ../git_patch_chipsbank_10_09_08:18: trailing whitespace.
>>           This is the driver of the Audio dsp (decoders and encoders )
>> ../git_patch_chipsbank_10_09_08:62: trailing whitespace.
>>   @Brief:  driver for cbm60xx audio dsp module
>> ../git_patch_chipsbank_10_09_08:91: trailing whitespace.
>> /**
>> ../git_patch_chipsbank_10_09_08:107: trailing whitespace.
>>      if ((id != chan- >index) || (fmt == chan- >format))
>> ../git_patch_chipsbank_10_09_08:109: trailing whitespace.
>>     return -1;
>> warning: squelched 696 whitespace errors
>> warning: 701 lines add whitespace errors.
>> [piet at pdelaney_fc9 xtensa-2.6.29-smp]$
>> -------------------------------------------------------------------------------------
>> I didn't expect any errors to be reported.
>> My current 'git status' is:
>> .......................................................................................
>> $ git status
>> # On branch IO_PORTS_Piggy_Back_On_Coprocessor_Infrastructure_Proposal
>> # Changes to be committed:
>> #   (use "git reset HEAD  <file >..." to unstage)
>> #
>> # modified:   drivers/media/Kconfig
>> # modified:   drivers/media/Makefile
>> # new file:   drivers/media/audio/Kconfig
>> # new file:   drivers/media/audio/Makefile
>> # new file:   drivers/media/audio/audio_dsp.c
>> # new file:   drivers/media/audio/audio_dsp.h
>> # new file:   drivers/media/audio/buffer.c
>> # new file:   drivers/media/audio/buffer.h
>> # new file:   drivers/media/audio/cbm60xx_dsp.c
>> # new file:   drivers/media/audio/cbm60xx_dsp.h
>> # new file:   drivers/media/audio/mailbox.c
>> # new file:   drivers/media/audio/mailbox.h
>> # new file:   drivers/media/audio/readme
>> ....................................................................................
>> I made a copy of 2.6.29-smp at linux-xtensa.org and called it "xtensa-2.6.29-smp-chipsbank.git".
>> I made you the owner with group access by folks in the chipsbank group.
>> As you can see the files are not accessible vie the git web access:
>> http://git.linux-xtensa.org/cgi-bin/git.cgi
>> it's only accessible by you and other members of the 'chipsbank'
>> group. I added Marc and myself as members of the group.
>> This approach allows our customers to keep their code un-published
>> until they are ready to push their changes to kernel.org.
>> Would it be ok for me to push your patch that I just applied there
>> so we are all on the same page? Feel free to push it your self;
>> which would really be a bit better. I recommend we make a branch
>> off of the proposed "IO_PORTS_Piggy_Back_On_Coprocessor_Infrastructure_Proposal"
>> branch.
>> In the mean time I'll try configuring it in and starting builds to put
>> together a bitstream for the LX200 with your cores on it.
>> So far it appears you git patch includes only the code run on the CB570TMMU.
>> Did I miss the code intended to run on the DC_330HiFi core?
>> The readme at the end of the git patch mentions dsp code and an application.
>> The dsp code is suppose to be in a 'dsp_code' dir. Looks like your using
>> the same xa_mp3_dec.a library that we use in the HiFi-2 SMP LX200 board:
>> http://wiki.linux-xtensa.org/index.php/Mplayer_Hifi_2_Codec_Development_Board
>> If ya go about 3/4 down the page to the section on compiling the Mplayer Plugins:
>>  Compiling the Mplayer Plugins and linking them with MPEG-1 Audio Layer 3 (MP3) and MPEG-4 AAC Codecs
>> you will see how we mount the codes's in an NFS mounted directory on the target
>> and then let the Makefile patch Mplayer with the codec library plugins.
>> In your case the Linux system isn't running with the HiFI-2 TIE instructions
>> and we have to do everything on our workstations. Do you have a makefile
>> to easily link the coded librarys to your test program? I suppose your
>> saying I should just make a trivial Makefile for your application and
>> have it link directly to the codec library's. If you have a tar ball
>> with the audio/test src and Makefile it would be good to send it
>> once I've got you cores running on an LX200. Looks like I'll have
>> a handful already with building the bitstream and messing around with
>> -piet

More information about the linux-xtensa mailing list