[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 23:40:50 PDT 2010

Piet Delaney wrote:
> Piet Delaney wrote:

I pushed a HACK to allow your driver to be used on the DC233 until
Tong can explain why/if doing more would be reasonable.

The DC233 only has I/O ports from what I've seen up to now,
the instructions to use them were a bit different. I'm hoping
it's enough to demonstrate your debug code showing that the
CPENABLE bit isn't being maintained correctly.

Marc, this repository can be cloned by:

	git clone git+ssh://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp-chipsbank.git

Here's the recent log related to the CPENABLE bit.
As always, I try explain in detail what I'm doing
to make it easy for others to follow:
commit 7730367be398eaf9071d04ad99d3538be6ecd742
Author: Pete Delaney <piet at tensilica.com>
Date:   Wed Sep 15 23:14:24 2010 -0700

     [XTENSA HACK] Just make's it so we can do some tesing of CPENABLE

     This HACK hopefully will allow us to use Turby's
     driver and test program to cause the CPENABLE bit
     to be set for that task. Invoking the task again
     should cause the bit to be set again for the new

     Signed-off-by: Pete Delaney <piet at tensilica.com>

commit 8abf7cd7f63f2cdba42a597fcbf41af85e520eef
Author: Pete Delaney <piet at tensilica.com>
Date:   Wed Sep 15 23:05:16 2010 -0700

     [XTENSA] Looks like using DMA is needed for dma_alloc_coherent().

     Signed-off-by: Pete Delaney <piet at tensilica.com>

commit 1d4582b0ec6c530df4e460096124a8fd8eb4b703
Author: Pete Delaney <piet at tensilica.com>
Date:   Wed Sep 15 18:43:56 2010 -0700

     [XTENSA] Truby's audio_ver0_03_2010_09_03 patch

     Signed-off-by: Pete Delaney <piet at tensilica.com>

commit 49dac0a2b2cdb0f61f7b28743cb2a352ae6b43a4
Author: Pete Delaney <piet at tensilica.com>
Date:   Tue Sep 7 00:55:04 2010 -0700

     [XTENSA] Fixed MMU V3 change for SMP

     Apparently I didn't check the MMU V3 change back on 20-Jly-2010 for SMP.
     The secondary reset vector was being defined incorrectly.

     Tested coprocessor change for I/O ports with SMP HiFi-2;
     as expected coprocessor code still works fine.

     Signed-off-by: Pete Delaney <piet at tensilica.com>

commit b44f784bdb5a8266b1d06d272e4e9f526408e41c
Author: Pete Delaney <piet at tensilica.com>
Date:   Mon Sep 6 18:45:20 2010 -0700

     [XTENSA] - Proposed 1st approach for supporting I/O Ports

     This approach is to piggy back on ALL of the existing coprocessor
     machinery and providing kernel support which provides security as
     long as the I/O ports are accessed in the process context.

     Alternate approaches and/or enhancements still being considered.
     Seems like an acceptable initial proposal. I tested it with tcp_sendmsg()
     accessing a port via two ssh sessions and it seems to work as I
     expected from reviewing the code. Interrupt handlers could set their
     CPENABLE bit and restore it when done. Perhaps a similar mechanism
     could be used for kernel support of use of coprocessor registers.
     This would be interesting for supporting AES co-processing. Likely
     the kernel and user space would have their own set of registers in
     the process context. This would allow them to continue with the current
     well documented lazy saved paradigm the hardware was designed for.

     The existing fast_coprocessor() code had a bug in it were support
     for coprocessors without any registers was missing a check for the
     Zero/NULL in the coprocessor jump tables for the jump offset.

     Signed-off-by: Pete Delaney <piet at tensilica.com>

I wrote a comment in coprocessor.S to explain the proposed concept:
+ * Macros used below to setup exception handlers for
+ * Coprocessor and I/O Ports. Currently coprocessors
+ * are owned by tasks in user space and I/O ports are
+ * owned by the kernel. Both coprocessors and I/O ports
+ * share the same exception causes and bit in the CPENABLE
+ * register.
+ *
+ * We could have a seperate fast_io_port() handler. It
+ * appears that the kernel excpetion handler assumes that
+ * we always have a thread_info structure with the current
+ * stack pointer so it should be safe to use the existing
+ * fast_coprocessor() code.
+ */

I'll do another test with my tcp_sendmsg() hack to try to verify
that the coprocessor I/O queue is owned by the current task and doesn't lose
it's ownership, Waiting for you (Truby) to push your bug fixes then we can test
it with your code which should print out nasty messages if it's being done wrong.

When pushing with git it's best to have your name on your workstation
being the same as on linux-xtensa.org. I can easily add and alias if
you want. Another approach is to put your login name in the git path.
Something like this:

     git clone git+ssh://truby@git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp-chipsbank.git
     passwd: chipsbank

You can also just update your .git/config file. It must have the +ssh to push to linux-xtensa.org.

Let me know if there is anything I can do to help.


> 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/
> eembc_consumer_noTie_cjpeg/
> [root at DC_C_233L default]# cd Chipbanks/
> [root at DC_C_233L Chipbanks]# ls
> test/
> [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
> r0x0
> 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
> project.
> 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
>> -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