RE: [patch/RESEND 2.6.29-rc3-git] NAND: davinci_nand driver
I and one of my colleague Vinod, who is no more with TI, worked on this driver. I can sign-off this driver. Signed-off-by: Sudhakar Rajashekhara Regards, Sudhakar > > On Thu, Feb 26, 2009 at 03:15:21PM -0800, David Brownell wrote: > > (To the TI team reading this via the DaVinci list: I think Andrew > > is hinting that a Signed-off-By from a TI person would be a Nice > > Thing. Same for Dirk, and maybe others.) > > If it's really necessary, feel free to add mine: > > Signed-off-by: Felipe Balbi > > -- > balbi > > ___ > 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
Video resizing
Hi all, I have a requirement that I get a video of any size from 1600x1200 to 320x240 to DM6446, I need to resize into PAL or NTSC resolution and encode into MPEG2 Video. I heard that VPFE will not be able to accept "any" video resolution, but only specific ones. Is it true? If so, what do I have to do specifically to capture it? Thanks, Gopal. DISCLAIMER: This message (including attachment if any) is confidential and may be privileged. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. E-mail may contain viruses. Before opening attachments please check them for viruses and defects. While MindTree Limited (MindTree) has put in place checks to minimize the risks, MindTree will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission. MindTree reserves the right to monitor and review the content of all messages sent to or from MindTree e-mail address. Messages sent to or from this e-mail address may be stored on the MindTree e-mail system or else where. http://www.mindtree.com/email/disclaimer.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Fwd: DM6446 Ethernet MAC performance
From: Pablo Bitton Date: Mon, Mar 2, 2009 at 11:52 AM Subject: Re: DM6446 Ethernet MAC performance To: "Subrahmanya, Chaithrika" Hi, I've found that the issue below can be demonstrated by compiling the following two revisions: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=commit;h=73af72ed66644dc3703b0bfd74285f30f1fe408f - before PHY refactoring http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=commit;h=b2cbe2f96aa420efcd312a1de8f7fd8e511b2a55 - after PHY refactoring Build commands used: $ make distclean $ make davinci_dm644x_evm_defconfig $ make uImage The kernels above were loaded to the same EVM, using the same network setup - and had the following performace: 73af72ed66644dc3703b0bfd74285f30f1fe408f - 72Mbit/s (upload) b2cbe2f96aa420efcd312a1de8f7fd8e511b2a55 - 21Mbit/s (upload) This experiment was repeated several times, so probably network congestion is not the reason for performance degradation seen. Regards, Pablo. On Wed, Feb 25, 2009 at 7:44 PM, Pablo Bitton wrote: > My host is Ubuntu 8.04, running over VMware, connected to DVEVM by 2 switches. > > I agree that this setup may cause network congestion. > However, I've ran iperf over DVEVM and the host several times - and > the results were pretty much the same. > > The only thing that made the throughput to change dramatically was > switching back and forth between 2.6.29-rc4 and 2.6.28-rc6. > > How should I debug this issue? > Are there any recommended profiling tools for kernel's network performance? > > Thanks in advance. > > On Tue, Feb 24, 2009 at 1:39 PM, Subrahmanya, Chaithrika > wrote: >>> Hi to all, >>> >>> I've tested Linux kernel 2.6.29-rc4-davinci1 >>> (http://git.kernel.org/?p=linux/kernel/git/khilman/linux- >>> davinci.git;a=commit;h=582ad6bcceb7c8f0c828e71e810fd40fed7af6c3) >>> for Ethernet performance. >>> Kernel was compiled was done by CodeSourcery 2008q3 (gcc 4.3.2) using >>> davinci_evm_dm644x_defconfig. >>> >>> After booting, iperf v2.0.4 was run on the target (DVEVM board) and on >>> the host PC (Ubuntu 8.04) for ten seconds (using default settings): >>> target -> target (over localhost): 190Mbit/s >>> host (connecting to) -> target: 31Mbit/s >>> target (connecting to) -> host: 71Mbit/s >>> >>> Do the values above make sense? Can anyone confirm them? >> >> The PHY layer should not cause any decrease in the performance as it >> is used only to access the PHY using the MII. Please provide some more >> details like the connection setup used- whether it was on a network >> or back to back. The network dynamics will alter the performance. >> >> Regards, >> Chaithrika >> >>> >>> Thanks in advance. >>> >>> P.S. >>> When running the same test on 2.6.28-rc6 (from >>> http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git), >>> before PHY was refactored out from davinci_emac, the results were >>> better: >>> host (connecting to) -> target: 73Mbit/s >>> target (connecting to) -> host: 57Mbit/s >>> >>> ___ >>> 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: Question on USB as host and device for Davinci based board
Nathael Pajani wrote: I'm trying to design a new custom board based on the TI Davinci DVEVM Board. Most of the decisions have been taken right now as of which parts to keep and which ones we will add, and some tests have been performed (as using a USB Hub to test for the possibility of having one onboard for the final version). But I still have one question: in the demo board manual it's said that switching from host to device for the USB must be done with the board turned off. Do you know if it will be possible to do it in software, and eventually with the board powered ? I know host and device will not be available at the same time, and I don't want this, but I would like that, for example, when the board is connected as device, the USB switches to "device mode", and when the cable is unplugged, it switches back to "host mode". From what I understand right now, this should be no problem with a little bit of driver development for the Linux kernel, but I'd like to know if some people have already done so, or if someone knows it is not possible due to the hardware or something alike. What you need is called USB On-The-Go (OTG). MUSB does support that, so it's surely possible. Thanks And have fun :) +++ 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: DM6467 - Encoding in 1080i with DMAI
Mahendra Kumar, very thanks. I will try it ASAP.
And look, it happened again. Some people said that it´s impossible. Others
said that yes, it can be done.
The doubt is spread over all forums and sites about it.
2009/2/23 Mahendra Kumar Angamuthu Ganesan
> Hi Marcelo Guedes,
>
> Change the source code of "capture.c" as shown below to make encoder of
> DM6467 demo working for 1080I as shown below and compile it.
>
> /* Calculate the dimensions of a video standard given a color space */
> #if RES_720
> if (BufferGfx_calcDimensions(VideoStd_720P_60,ColorSpace_YUV422PSEMI,
> &gfxAttrs.dim) < 0) {
> #else
> if (BufferGfx_calcDimensions(VideoStd_1080I_30, ColorSpace_YUV422PSEMI,
> &gfxAttrs.dim) < 0) {
> #endif
> ERR("Failed to calculate Buffer dimensions\n");
> cleanup(THREAD_FAILURE);
> }
>
> /* Calculate buffer size needed of a video standard given a color space
> */
> #if RES_720
> bufSize = BufferGfx_calcSize(VideoStd_720P_60, ColorSpace_YUV422PSEMI);
> #else
> bufSize = BufferGfx_calcSize(VideoStd_1080I_30,
> ColorSpace_YUV422PSEMI);
> #endif
>
> if (bufSize < 0) {
> ERR("Failed to calculate size for capture driver buffers\n");
> cleanup(THREAD_FAILURE);
> }
>
> /* Create a table of buffers to use with the device drivers */
> gfxAttrs.colorSpace = ColorSpace_YUV422PSEMI;
> hBufTab = BufTab_create(NUM_DRIVER_BUFS, bufSize,
> BufferGfx_getBufferAttrs(&gfxAttrs));
>
> if (hBufTab == NULL) {
> ERR("Failed to allocate contiguous buffers\n");
> cleanup(THREAD_FAILURE);
> }
>
> /* Create capture device driver instance */
> cAttrs.numBufs = NUM_CAPTURE_BUFS;
> hCapture = Capture_create(hBufTab, &cAttrs);
>
> if (hCapture == NULL) {
> ERR("Failed to create capture device, "
> "720P component input connected?\n");
> cleanup(THREAD_FAILURE);
> }
>
> videoStd = Capture_getVideoStd(hCapture);
>
> /* We only support 720P capture */
> #if RES_720
> if (videoStd != VideoStd_720P_50 && videoStd != VideoStd_720P_60) {
> #else
> if (videoStd != VideoStd_1080I_30 && videoStd != VideoStd_1080P_30) {
> #endif
> ERR("Need 720P composite input to this demo\n");
> cleanup(THREAD_FAILURE);
> }
>
>
>
> Then you should change the memory configuration of the encoder to work for
> 1080I. So please change the loadmodules.sh script as shown below before
> running the encode demo.
>
> # insert cmemk, tell it to occupy physical 120MB-200MB and create enough
> # contiguous buffers for the worst case requirements of the demos.
> rmmod cmemk.ko
> # one times 4MB, 10 times 3.5 MB,10 times 1.5MB etc
> #insmod cmemk.ko phys_start=0x8780 phys_end=0x8ba0
> pools=1x4147200,10x3458400,10x1434240,11x663552,4x6
>
> # 10 times 4MB, 1 times 3.5 MB,10 times 1.5MB etc
> insmod cmemk.ko phys_start=0x8780 phys_end=0x8ba0
> pools=10x4147200,1x3458400,10x1434240,11x663552,4x6
>
> # insert dsplinkk, tell it that DSP's DDR is at physical 250MB-254MB
> rmmod dsplinkk.ko
> insmod dsplinkk.ko
>
> # alter dma queue mapping for better visual performance
> if [ -f mapdmaq-hd ]
> then
> ./mapdmaq-hd
> fi
>
> # make /dev/dsplink
> rm -f /dev/dsplink
> mknod /dev/dsplink c `awk "\\$2==\"dsplink\" {print \\$1}" /proc/devices` 0
>
>
> This should make it working for 1080.
>
>
> Currently the encoder will not encode at 30 frames persecond. I do not
> remember exactly how many frames per second it can encode.
>
>
>
>
> Regards,
> Mahendra kumar
>
>
>
>
>
>
> ___
> 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 2.6.29-rc5-git] usb/musb: make Davinci *work* in mainline
David Brownell wrote: Now that the musb build fixes for DaVinci got merged (RC3?), kick in the other bits needed to get it finally *working* in mainline: - Use clk_enable()/clk_disable() ... the "always enable USB clocks" code this originally relied on has since been removed. - Initialize the USB device only after the relevant I2C GPIOs are available, so the host side can properly enable VBUS. - Tweak init sequencing to cope with mainline's relatively late init of the I2C system bus for power switches, transceivers, and so on. Sanity tested on DM6664 EVM for host and peripheral modes; that system Wow, that must be a totally new kind of DaVinci! :-) won't boot with CONFIG_PM enabled, so OTG can't yet be tested. BTW, could somebody clarify why OTG is coupled with PM? Also verified on OMAP3. 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: Video resizing
Hello, VPFE hardware can support HDTV(720p/1080i) resolution in turbo mode. You may need to use external CMOS sensor to capture HDTV resolution image. Check VPFE doc for more info on clocking etc. Also note that Resizer module supports upscaling upto 4x and down-scaling upto 1/4x. See resizer doc for more information. Thanks -Brijesh Singh From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Gopal Sukumar Sent: Monday, March 02, 2009 2:58 AM To: DaVinciMailingList Subject: Video resizing Hi all, I have a requirement that I get a video of any size from 1600x1200 to 320x240 to DM6446, I need to resize into PAL or NTSC resolution and encode into MPEG2 Video. I heard that VPFE will not be able to accept "any" video resolution, but only specific ones. Is it true? If so, what do I have to do specifically to capture it? Thanks, Gopal. DISCLAIMER: This message (including attachment if any) is confidential and may be privileged. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. E-mail may contain viruses. Before opening attachments please check them for viruses and defects. While MindTree Limited (MindTree) has put in place checks to minimize the risks, MindTree will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission. MindTree reserves the right to monitor and review the content of all messages sent to or from MindTree e-mail address. Messages sent to or from this e-mail address may be stored on the MindTree e-mail system or else where. http://www.mindtree.com/email/disclaimer.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: TI's Gstreamer plugin cannot be found by 'playbin' ?
Hello Zhenfeng This is one the known issue listed in tracker item, https://omapzoom.org/gf/project/gstreamer_ti/tracker/?action=TrackerItemEdit&tracker_item_id=253. Patch is welcome. There is a function to register plugin, check ti_build/ticodecplugin/src/gstticodecplugin.c: TICodecPlugin_init(). You can control the registered elements with this function. Thanks Brijesh Singh -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of zhenfeng ren Sent: Sunday, March 01, 2009 8:35 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: TI's Gstreamer plugin cannot be found by 'playbin' ? hi,everyone: If I use the fellow script, it work well. gst-launch --gst-debug-no-color --gst-debug=TI*:2 filesrc location=mp4.ts ! typefind ! mpegtsdemux name=demux demux. ! audio/mpeg ! queue max-size-buffers=1200 max-size-time=0 max-size-bytes=0 ! typefind ! TIAuddec ! audioconvert ! osssink demux. ! video/mpeg ! typefind ! TIViddec ! TIDmaiVideoSink displayStd=fbdev displayDevice=/dev/fb/3 videoStd=D1_NTSC videoOutput=COMPOSITE resizer=FALSE accelFrameCopy=TRUE but if I use 'palybin', TI's plugin couldnot be found by 'playbin'. As: r...@dvevm:/opt# gst-launch -v playbin uri=file:///opt/gstreamer_demo/dm6446/mp4.ts (gst-launch-0.10:1264): GStreamer-WARNING **: Failed to load plugin '/opt/gstreamer/lib/gstreamer-0.10//libgstmad.so': /opt/gstreamer/lib/libid3tag.so.0: undefi ned symbol: id3_frametype_unknown Setting pipeline to PAUSED ... /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188 Pipeline is PREROLLING ... /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstMpegTSDemux:mpegtsdemux0.GstPad:sink: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188 /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstMpegTSDemux:mpegtsdemux0: pat-info = ((GValueArray*) 0x36a10) /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstMpegTSDemux:mpegtsdemux0: pmt-info = ((FluTsPmtInfo*) 0x35640) ** Message: don't know how to handle video/mpeg, mpegversion=(int)4, systemstream=(boolean)false ** Message: don't know how to handle audio/mpeg, mpegversion=(int)4 I see that TI's plugins donot have founction 'plungin_init' as other plungins. Could anyone give me some advice? -- 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: Dmai + Transparency
Hello, DMAI does not have API to control window attributes (like transparency/blending etc). Thanks Brijesh Singh -Original Message- From: davinci-linux-open-source-bounces+bksingh=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+bksingh=ti@linux.davincidsp.com] On Behalf Of Nitin Mahajan Sent: Monday, March 02, 2009 1:00 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Dmai + Transparency HI! I just wanted to check , whether there are any APIs in DMAI, which would help control the transparency between OSD0 and video windows? regards -Nitin Get your preferred Email name! Now you can @ymail.com and @rocketmail.com. http://mail.promotions.yahoo.com/newdomains/aa/ ___ 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: DM6446 Ethernet MAC performance
> From: Pablo Bitton > Date: Mon, Mar 2, 2009 at 11:52 AM > Subject: Re: DM6446 Ethernet MAC performance > To: "Subrahmanya, Chaithrika" > > > Hi, > > I've found that the issue below can be demonstrated by compiling the > following two revisions: > http://git.kernel.org/?p=linux/kernel/git/khilman/linux- > davinci.git;a=commit;h=73af72ed66644dc3703b0bfd74285f30f1fe408f > - before PHY refactoring > http://git.kernel.org/?p=linux/kernel/git/khilman/linux- > davinci.git;a=commit;h=b2cbe2f96aa420efcd312a1de8f7fd8e511b2a55 > - after PHY refactoring > > Build commands used: > $ make distclean > $ make davinci_dm644x_evm_defconfig > $ make uImage > > The kernels above were loaded to the same EVM, using the same network > setup - and had the following performace: > 73af72ed66644dc3703b0bfd74285f30f1fe408f - 72Mbit/s (upload) > b2cbe2f96aa420efcd312a1de8f7fd8e511b2a55 - 21Mbit/s (upload) > > This experiment was repeated several times, so probably network > congestion is not the reason for performance degradation seen. > I am looking into this issue, will get back to you with my findings. I have not observed any large difference in performance numbers when I tested it earlier (for UDP). In fact there was some improvement for some cases. Thanks, Chaithrika > Regards, > Pablo. > > On Wed, Feb 25, 2009 at 7:44 PM, Pablo Bitton > wrote: > > My host is Ubuntu 8.04, running over VMware, connected to DVEVM by 2 > switches. > > > > I agree that this setup may cause network congestion. > > However, I've ran iperf over DVEVM and the host several times - and > > the results were pretty much the same. > > > > The only thing that made the throughput to change dramatically was > > switching back and forth between 2.6.29-rc4 and 2.6.28-rc6. > > > > How should I debug this issue? > > Are there any recommended profiling tools for kernel's network > performance? > > > > Thanks in advance. > > > > On Tue, Feb 24, 2009 at 1:39 PM, Subrahmanya, Chaithrika > > wrote: > >>> Hi to all, > >>> > >>> I've tested Linux kernel 2.6.29-rc4-davinci1 > >>> (http://git.kernel.org/?p=linux/kernel/git/khilman/linux- > >>> davinci.git;a=commit;h=582ad6bcceb7c8f0c828e71e810fd40fed7af6c3) > >>> for Ethernet performance. > >>> Kernel was compiled was done by CodeSourcery 2008q3 (gcc 4.3.2) > using > >>> davinci_evm_dm644x_defconfig. > >>> > >>> After booting, iperf v2.0.4 was run on the target (DVEVM board) and > on > >>> the host PC (Ubuntu 8.04) for ten seconds (using default settings): > >>> target -> target (over localhost): 190Mbit/s > >>> host (connecting to) -> target: 31Mbit/s > >>> target (connecting to) -> host: 71Mbit/s > >>> > >>> Do the values above make sense? Can anyone confirm them? > >> > >> The PHY layer should not cause any decrease in the performance as it > >> is used only to access the PHY using the MII. Please provide some > more > >> details like the connection setup used- whether it was on a network > >> or back to back. The network dynamics will alter the performance. > >> > >> Regards, > >> Chaithrika > >> > >>> > >>> Thanks in advance. > >>> > >>> P.S. > >>> When running the same test on 2.6.28-rc6 (from > >>> http://git.kernel.org/?p=linux/kernel/git/khilman/linux- > davinci.git), > >>> before PHY was refactored out from davinci_emac, the results were > >>> better: > >>> host (connecting to) -> target: 73Mbit/s > >>> target (connecting to) -> host: 57Mbit/s > >>> > >>> ___ > >>> Davinci-linux-open-source mailing list > >>> Davinci-linux-open-source@linux.davincidsp.com > >>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > source > > > > ___ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: TI's Gstreamer plugin cannot be found by 'playbin' ?
Hi Zhenfeng, I have people looking on this issue for Beagleboard, and we have the playbin and decodebin locating the plugins properly. Probably is something wrong with your environment. Please post your issue on a bug entry, and provide the output with GST_DEBUG=3 environment set. Diego Dompe RidgeRun On Mar 1, 2009, at 8:34 PM, zhenfeng ren wrote: hi,everyone: If I use the fellow script, it work well. gst-launch --gst-debug-no-color --gst-debug=TI*:2 filesrc location=mp4.ts ! typefind ! mpegtsdemux name=demux demux. ! audio/mpeg ! queue max-size-buffers=1200 max-size-time=0 max-size-bytes=0 ! typefind ! TIAuddec ! audioconvert ! osssink demux. ! video/mpeg ! typefind ! TIViddec ! TIDmaiVideoSink displayStd=fbdev displayDevice=/dev/fb/3 videoStd=D1_NTSC videoOutput=COMPOSITE resizer=FALSE accelFrameCopy=TRUE but if I use 'palybin', TI's plugin couldnot be found by 'playbin'. As: r...@dvevm:/opt# gst-launch -v playbin uri=file:///opt/gstreamer_demo/dm6446/mp4.ts (gst-launch-0.10:1264): GStreamer-WARNING **: Failed to load plugin '/opt/gstreamer/lib/gstreamer-0.10//libgstmad.so': /opt/gstreamer/lib/libid3tag.so.0: undefi ned symbol: id3_frametype_unknown Setting pipeline to PAUSED ... /GstPlayBin:playbin0/GstDecodeBin:decodebin0/ GstTypeFindElement:typefind.GstPad:src: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188 Pipeline is PREROLLING ... /GstPlayBin:playbin0/GstDecodeBin:decodebin0/ GstMpegTSDemux:mpegtsdemux0.GstPad:sink: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188 /GstPlayBin:playbin0/GstDecodeBin:decodebin0/ GstMpegTSDemux:mpegtsdemux0: pat-info = ((GValueArray*) 0x36a10) /GstPlayBin:playbin0/GstDecodeBin:decodebin0/ GstMpegTSDemux:mpegtsdemux0: pmt-info = ((FluTsPmtInfo*) 0x35640) ** Message: don't know how to handle video/mpeg, mpegversion=(int)4, systemstream=(boolean)false ** Message: don't know how to handle audio/mpeg, mpegversion=(int)4 I see that TI's plugins donot have founction 'plungin_init' as other plungins. Could anyone give me some advice? -- 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
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) issue
Hello All, I just stared building the kernel with GIT repository. Currently I am having Linux-2.6.29-rc4. Referring to the link http://wiki.davincidsp.com/index.php?title=Linux_Toolchain#Clone_recent_open_source_Linux_kernel_git for building the kernel. I am unable to mount the rootfs. Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) My root is on the ATA base disk (hda: TOSHIBA MK4032GAX, ATA DISK drive). I don't find the kernel configure option to enable it to make the driver as part of the kernel. If incase any body come across the issue or has the patches needed, please update. Thanks, Arun http://www.mindtree.com/email/disclaimer.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: DM6446 Ethernet MAC performance
Hi,
I forgot to mention that I've used iperf's TCP throughput test, with the
following settings:
$ iperf -s # for running a TCP server
$ iperf -c {server's IP address} -i 1 # for running a TCP client
Thanks for helping me out,
Pablo.
On Mon, Mar 2, 2009 at 3:54 PM, Subrahmanya, Chaithrika
wrote:
> > From: Pablo Bitton
> > Date: Mon, Mar 2, 2009 at 11:52 AM
> > Subject: Re: DM6446 Ethernet MAC performance
> > To: "Subrahmanya, Chaithrika"
> >
> >
> > Hi,
> >
> > I've found that the issue below can be demonstrated by compiling the
> > following two revisions:
> > http://git.kernel.org/?p=linux/kernel/git/khilman/linux-
> > davinci.git;a=commit;h=73af72ed66644dc3703b0bfd74285f30f1fe408f
> > - before PHY refactoring
> > http://git.kernel.org/?p=linux/kernel/git/khilman/linux-
> > davinci.git;a=commit;h=b2cbe2f96aa420efcd312a1de8f7fd8e511b2a55
> > - after PHY refactoring
> >
> > Build commands used:
> > $ make distclean
> > $ make davinci_dm644x_evm_defconfig
> > $ make uImage
> >
> > The kernels above were loaded to the same EVM, using the same network
> > setup - and had the following performace:
> > 73af72ed66644dc3703b0bfd74285f30f1fe408f - 72Mbit/s (upload)
> > b2cbe2f96aa420efcd312a1de8f7fd8e511b2a55 - 21Mbit/s (upload)
> >
> > This experiment was repeated several times, so probably network
> > congestion is not the reason for performance degradation seen.
> >
>
> I am looking into this issue, will get back to you with my findings.
> I have not observed any large difference in performance numbers
> when I tested it earlier (for UDP). In fact there was some
> improvement for some cases.
>
> Thanks,
> Chaithrika
>
> > Regards,
> > Pablo.
> >
> > On Wed, Feb 25, 2009 at 7:44 PM, Pablo Bitton
> > wrote:
> > > My host is Ubuntu 8.04, running over VMware, connected to DVEVM by 2
> > switches.
> > >
> > > I agree that this setup may cause network congestion.
> > > However, I've ran iperf over DVEVM and the host several times - and
> > > the results were pretty much the same.
> > >
> > > The only thing that made the throughput to change dramatically was
> > > switching back and forth between 2.6.29-rc4 and 2.6.28-rc6.
> > >
> > > How should I debug this issue?
> > > Are there any recommended profiling tools for kernel's network
> > performance?
> > >
> > > Thanks in advance.
> > >
> > > On Tue, Feb 24, 2009 at 1:39 PM, Subrahmanya, Chaithrika
> > > wrote:
> > >>> Hi to all,
> > >>>
> > >>> I've tested Linux kernel 2.6.29-rc4-davinci1
> > >>> (http://git.kernel.org/?p=linux/kernel/git/khilman/linux-
> > >>> davinci.git;a=commit;h=582ad6bcceb7c8f0c828e71e810fd40fed7af6c3)
> > >>> for Ethernet performance.
> > >>> Kernel was compiled was done by CodeSourcery 2008q3 (gcc 4.3.2)
> > using
> > >>> davinci_evm_dm644x_defconfig.
> > >>>
> > >>> After booting, iperf v2.0.4 was run on the target (DVEVM board) and
> > on
> > >>> the host PC (Ubuntu 8.04) for ten seconds (using default settings):
> > >>> target -> target (over localhost): 190Mbit/s
> > >>> host (connecting to) -> target: 31Mbit/s
> > >>> target (connecting to) -> host: 71Mbit/s
> > >>>
> > >>> Do the values above make sense? Can anyone confirm them?
> > >>
> > >> The PHY layer should not cause any decrease in the performance as it
> > >> is used only to access the PHY using the MII. Please provide some
> > more
> > >> details like the connection setup used- whether it was on a network
> > >> or back to back. The network dynamics will alter the performance.
> > >>
> > >> Regards,
> > >> Chaithrika
> > >>
> > >>>
> > >>> Thanks in advance.
> > >>>
> > >>> P.S.
> > >>> When running the same test on 2.6.28-rc6 (from
> > >>> http://git.kernel.org/?p=linux/kernel/git/khilman/linux-
> > davinci.git),
> > >>> before PHY was refactored out from davinci_emac, the results were
> > >>> better:
> > >>> host (connecting to) -> target: 73Mbit/s
> > >>> target (connecting to) -> host: 57Mbit/s
> > >>>
> > >>> ___
> > >>> Davinci-linux-open-source mailing list
> > >>> Davinci-linux-open-source@linux.davincidsp.com
> > >>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-
> > source
> > >
> >
> > ___
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source@linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/2] musb_gadget: suppress "parasitic" Tx interrupts with CPPI DMA driver
Suppress "parasitic" endpoint interrupts in the DMA mode when using CPPI DMA driver; they're caused by the MUSB gadget driver using the DMA request mode 0 instead of the mode 1. Signed-off-by: Sergei Shtylyov --- This patch is atop of the current Linus' tree... drivers/usb/musb/musb_gadget.c |3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) Index: linux-2.6/drivers/usb/musb/musb_gadget.c === --- linux-2.6.orig/drivers/usb/musb/musb_gadget.c +++ linux-2.6/drivers/usb/musb/musb_gadget.c @@ -349,7 +349,8 @@ static void txstate(struct musb *musb, s #elif defined(CONFIG_USB_TI_CPPI_DMA) /* program endpoint CSR first, then setup DMA */ csr &= ~(MUSB_TXCSR_P_UNDERRUN | MUSB_TXCSR_TXPKTRDY); - csr |= MUSB_TXCSR_MODE | MUSB_TXCSR_DMAENAB; + csr |= MUSB_TXCSR_DMAENAB | MUSB_TXCSR_DMAMODE | + MUSB_TXCSR_MODE; musb_writew(epio, MUSB_TXCSR, (MUSB_TXCSR_P_WZC_BITS & ~MUSB_TXCSR_P_UNDERRUN) | csr); ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/2] MUSB: fix unhandled gadget endpoint 0 IRQs
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.
The driver also prematurely leaves the status phase on receiving the SetupEnd
interrupt...
As there were still unhandled endpoint 0 interrupts happening from time to
time after fixing these issues, there turned to be yet another culprit: two
distinct gadget states collapsed into one. The state that comes after STATUS
IN/OUT states is typically indiscernible from them since the corresponding
interrupts tend to happen within too little period of time (due to only a
zero-length status packet in between) and so they get coalesced; yet this
state is not the same as the next one which is associated with the reception
of a SETUP packet.
Adding this extra state seems to have fixed the rest of unhandled interrupts
that generic_interrupt() and davinci_interrupt() hid from user by faking their
result and only emitting a debug message -- so, stop doing that...
Signed-off-by: Sergei Shtylyov
---
This patch are is atop of the Linus' tree plus 3 more patches posted earlier
that haven't made it into any tree yet:
http://marc.info/?l=linux-usb&m=123502258502676
http://marc.info/?l=linux-usb&m=123558766411239
http://marc.info/?l=linux-usb&m=123516211401715
drivers/usb/musb/davinci.c |7 -
drivers/usb/musb/musb_core.c |8 --
drivers/usb/musb/musb_core.h |3 +-
drivers/usb/musb/musb_gadget_ep0.c | 45 -
4 files changed, 43 insertions(+), 20 deletions(-)
Index: linux-2.6/drivers/usb/musb/davinci.c
===
--- linux-2.6.orig/drivers/usb/musb/davinci.c
+++ linux-2.6/drivers/usb/musb/davinci.c
@@ -357,12 +357,7 @@ static irqreturn_t davinci_interrupt(int
spin_unlock_irqrestore(&musb->lock, flags);
- /* REVISIT we sometimes get unhandled IRQs
-* (e.g. ep0). not clear why...
-*/
- if (retval != IRQ_HANDLED)
- DBG(5, "unhandled? %08x\n", tmp);
- return IRQ_HANDLED;
+ return retval;
}
int musb_platform_set_mode(struct musb *musb, u8 mode)
Index: linux-2.6/drivers/usb/musb/musb_core.c
===
--- linux-2.6.orig/drivers/usb/musb/musb_core.c
+++ linux-2.6/drivers/usb/musb/musb_core.c
@@ -1481,13 +1481,7 @@ static irqreturn_t generic_interrupt(int
spin_unlock_irqrestore(&musb->lock, flags);
- /* REVISIT we sometimes get spurious IRQs on g_ep0
-* not clear why...
-*/
- if (retval != IRQ_HANDLED)
- DBG(5, "spurious?\n");
-
- return IRQ_HANDLED;
+ return retval;
}
#else
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
@@ -171,7 +171,8 @@ enum musb_h_ep0_state {
/* peripheral side ep0 states */
enum musb_g_ep0_state {
- MUSB_EP0_STAGE_SETUP, /* idle, waiting for setup */
+ MUSB_EP0_STAGE_IDLE,/* idle, waiting for SETUP */
+ MUSB_EP0_STAGE_SETUP, /* received SETUP */
MUSB_EP0_STAGE_TX, /* IN data */
MUSB_EP0_STAGE_RX, /* OUT data */
MUSB_EP0_STAGE_STATUSIN,/* (after OUT data) */
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
@@ -4,6 +4,7 @@
* Copyright 2005 Mentor Graphics Corporation
* Copyright (C) 2005-2006 by Texas Instruments
* Copyright (C) 2006-2007 Nokia Corporation
+ * Copyright (C) 2008-2009 MontaVista Software, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -58,7 +59,8 @@
static char *decode_ep0stage(u8 stage)
{
switch (stage) {
- case MUSB_EP0_STAGE_SETUP: return "idle";
+ case MUSB_EP0_STAGE_IDLE: return "idle";
+ case MUSB_EP0_STAGE_SETUP: return "setup";
case MUSB_EP0_STAGE_TX: return "in";
case MUSB_EP0_STAGE_RX: return "out";
case MUSB_EP0_STAGE_ACKWAIT:return "wait";
@@ -628,7 +630,7 @@ irqreturn_t musb_g_ep0_irq(struct musb *
musb_writew(regs, MUSB_CSR0,
csr & ~MUSB_CSR0_P_SENTSTALL);
retval = IRQ_HANDLED;
- musb->ep0_state = MUSB_EP0_STAGE_SETUP;
+ musb->ep0_state = MUSB_EP0_STAGE_IDLE;
csr = musb_readw(regs, MUSB_CSR0);
}
@@ -636,7 +638,18 @@ irqreturn_t musb_g_ep0_irq(struct musb *
if (csr & MUSB_CSR0_P_SETUPEND) {
musb_writew(regs, MUSB_CSR0, M
Re: DM6467 - Encoding in 1080i with DMAI
Hi, it didn´t work.
I ran the new loadmodules.sh and received this message:
r...@10.0.0.100:/opt/dvsdk# ./loadmodules.sh
> ioremap_nocache(0x8780, 69206016)=0xc808
> allocated heap buffer 0xc808 of size 0x239000
> cmem initialized 5 pools between 0x8780 and 0x8ba0
> DSPLINK Module (1.50) created on Date: Jan 3 2008 Time: 13:16:55
>
Seems to be right, but when I tried to run the encode program (with the
modified capture.c), I received this error:
r...@10.0.0.100:/opt/dvsdk# ./encode -a audio.aac -v video.264
> Encode demo started.
> Error: Failed to create h264 video encoder
I have an extra information. I don´t know if this help but I modified
capture.c to receive 480P and it worked properly. I made the same list of
modifications that you put here, but to 480P, and worked fine.
I think you should pay attention in this lines:
# one times 4MB, 10 times 3.5 MB,10 times 1.5MB etc
> #insmod cmemk.ko phys_start=0x8780 phys_end=0x8ba0
> pools=1x4147200,10x3458400,10x1434240,11x663552,4x6
>
> # 10 times 4MB, 1 times 3.5 MB,10 times 1.5MB etc
> insmod cmemk.ko phys_start=0x8780 phys_end=0x8ba0
> pools=10x4147200,1x3458400,10x1434240,11x663552,4x6
>
Instead of the comment symbol and the info text, both are equal. Is it
right?
Thanks for the help.
On Mon, Mar 2, 2009 at 8:11 AM, Marcelo Guedes Silva <
marcelo.gue...@gmail.com> wrote:
> Mahendra Kumar, very thanks. I will try it ASAP.
> And look, it happened again. Some people said that it´s impossible. Others
> said that yes, it can be done.
>
> The doubt is spread over all forums and sites about it.
>
> 2009/2/23 Mahendra Kumar Angamuthu Ganesan
>
>> Hi Marcelo Guedes,
>>
>> Change the source code of "capture.c" as shown below to make encoder of
>> DM6467 demo working for 1080I as shown below and compile it.
>>
>> /* Calculate the dimensions of a video standard given a color space */
>> #if RES_720
>> if (BufferGfx_calcDimensions(VideoStd_720P_60,ColorSpace_YUV422PSEMI,
>> &gfxAttrs.dim) < 0) {
>> #else
>> if (BufferGfx_calcDimensions(VideoStd_1080I_30,
>> ColorSpace_YUV422PSEMI, &gfxAttrs.dim) < 0) {
>> #endif
>> ERR("Failed to calculate Buffer dimensions\n");
>> cleanup(THREAD_FAILURE);
>> }
>>
>> /* Calculate buffer size needed of a video standard given a color
>> space */
>> #if RES_720
>> bufSize = BufferGfx_calcSize(VideoStd_720P_60,
>> ColorSpace_YUV422PSEMI);
>> #else
>> bufSize = BufferGfx_calcSize(VideoStd_1080I_30,
>> ColorSpace_YUV422PSEMI);
>> #endif
>>
>> if (bufSize < 0) {
>> ERR("Failed to calculate size for capture driver buffers\n");
>> cleanup(THREAD_FAILURE);
>> }
>>
>> /* Create a table of buffers to use with the device drivers */
>> gfxAttrs.colorSpace = ColorSpace_YUV422PSEMI;
>> hBufTab = BufTab_create(NUM_DRIVER_BUFS, bufSize,
>> BufferGfx_getBufferAttrs(&gfxAttrs));
>>
>> if (hBufTab == NULL) {
>> ERR("Failed to allocate contiguous buffers\n");
>> cleanup(THREAD_FAILURE);
>> }
>>
>> /* Create capture device driver instance */
>> cAttrs.numBufs = NUM_CAPTURE_BUFS;
>> hCapture = Capture_create(hBufTab, &cAttrs);
>>
>> if (hCapture == NULL) {
>> ERR("Failed to create capture device, "
>> "720P component input connected?\n");
>> cleanup(THREAD_FAILURE);
>> }
>>
>> videoStd = Capture_getVideoStd(hCapture);
>>
>> /* We only support 720P capture */
>> #if RES_720
>> if (videoStd != VideoStd_720P_50 && videoStd != VideoStd_720P_60) {
>> #else
>> if (videoStd != VideoStd_1080I_30 && videoStd != VideoStd_1080P_30) {
>> #endif
>> ERR("Need 720P composite input to this demo\n");
>> cleanup(THREAD_FAILURE);
>> }
>>
>>
>>
>> Then you should change the memory configuration of the encoder to work for
>> 1080I. So please change the loadmodules.sh script as shown below before
>> running the encode demo.
>>
>> # insert cmemk, tell it to occupy physical 120MB-200MB and create enough
>> # contiguous buffers for the worst case requirements of the demos.
>> rmmod cmemk.ko
>> # one times 4MB, 10 times 3.5 MB,10 times 1.5MB etc
>> #insmod cmemk.ko phys_start=0x8780 phys_end=0x8ba0
>> pools=1x4147200,10x3458400,10x1434240,11x663552,4x6
>>
>> # 10 times 4MB, 1 times 3.5 MB,10 times 1.5MB etc
>> insmod cmemk.ko phys_start=0x8780 phys_end=0x8ba0
>> pools=10x4147200,1x3458400,10x1434240,11x663552,4x6
>>
>> # insert dsplinkk, tell it that DSP's DDR is at physical 250MB-254MB
>> rmmod dsplinkk.ko
>> insmod dsplinkk.ko
>>
>> # alter dma queue mapping for better visual performance
>> if [ -f mapdmaq-hd ]
>> then
>> ./mapdmaq-hd
>> fi
>>
>> # make /dev/dsplink
>> rm -f /dev/dsplink
>> mknod /dev/dsplink c `awk "\\$2==\"dsplink\" {print \\$1}" /proc/devices`
>> 0
>>
>>
>> This should make it working for 1080.
>>
>>
>> Currently the encoder will not encode at 30 frames persecond
Re: [patch 2.6.29-rc5-git] usb/musb: make Davinci *work* in mainline
On Monday 02 March 2009, Sergei Shtylyov wrote: > > won't boot with CONFIG_PM enabled, so OTG can't yet be tested. > > BTW, could somebody clarify why OTG is coupled with PM? Because HNP depends on what's now USB_SUSPEND, which in turn depends on PM ... and OTG requires HNP. The dependencies may be a bit screwed up by now. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Hand written assembly code
You need to write your assembly to handle interrupts properly. For example, you need to make sure that the stack pointer is double-word aligned at any time where interrupts are enabled. That means you could not do two "pushes" in a row to the stack. Rather you would need to increment the stack by 2 words and then use an indexed address mode to write the words into the space you just allocated. If you follow the guidelines in the C Compiler Guide *precisely* then you'll find many of these things are taken care of. If you're using the SPLOOP hardware instead of writing software-pipelined loops then that will allow you to have interruptible code. Brad > -Original Message- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf > Of Zuber > Sent: Friday, February 27, 2009 12:21 AM > To: davinci-linux-open-source@linux.davincidsp.com > Subject: Hand written assembly code > > Hi All, > > I am working on video codec optimization. In this,to get more > optimization i have converted some of c functions in to the assembly. > Now my question is, will this hand written assembly creates problems in > terms of interrupt handling. > Because i heard from some one that hand written assembly would not > handle interrupts properly. > So can anybody explain or confirm me about such issue or any other > suggestion related to this will help me to go further. > > -- > Regards, > Zuber Saiyed > Embedded Engineer > e-Infochips Ltd. > 11/A-B, Chandra Colony, Off C.G. Road, > Ellisbridge, Ahmedabad - 380006 > Telephone :- 079-2656 3705 Ext :- 126 > www.einfochips.com > > -- > _ > Disclaimer: This e-mail message and all attachments transmitted with it > are intended solely for the use of the addressee and may contain legally > privileged and confidential information. If the reader of this message > is not the intended recipient, or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution, copying, or other use of > this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any > views expressed in this message are those of the individual sender > unless otherwise stated.Company has taken enough precautions to prevent > the spread of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > __ > > > ___ > 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
DM355 daughter sound card problem
Hi All, I am developing driver for daughter sound card on DM355 by modifying the AIC33 driver. I2C is working fine and the ioctl's are working fine but recording is not working. There are 2 McBSP bus (McBSP1 and McBSP2) used for DMA transfer out of which McBSP1 is used for the sound daughter card. Audio format is I2S. Following is the configuration that I tried: #define DEFAULT_BITPERSAMPLE 256 #define AUDIO_RATE_DEFAULT 8000 #defineAUDIO_MCBSP DAVINCI_MCBSP1 McBSP1 is configured as slave for recording. Below is configuration for McBSP1: .spcr2 = FREE | XINTM(3), .spcr1 = RINTM(3), .rcr2 = RWDLEN2(DAVINCI_MCBSP_WORD_16) | RDATDLY(1), .rcr1 = RFRLEN1(1) | RWDLEN1(DAVINCI_MCBSP_WORD_16), .xcr2 = XWDLEN2(DAVINCI_MCBSP_WORD_16) | XDATDLY(1) | XFIG, .xcr1 = XFRLEN1(1) | XWDLEN1(DAVINCI_MCBSP_WORD_16), .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1), .srgr2 = FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1), /* configure McBSP to be the I2S master */ .pcr0 = FSXM | FSRM | CLKXM | CLKRM | CLKXP | CLKRP, Daughter card is configured for 16bit word, 8000KHz and 256bits per sample. AIC33 uses McBSP2 while my audio daughter card uses McBSP1. Also, the default bits per sample for AIC33 is 16, I've changed it to 256. But I don't get any interrupt for recording. Please can anyone help to sort out the problem. Thanks, Azam. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
