Hi, To compile the USB Driver with logging level 0, move Otg_state_string() implementation into davinci.c .
Regards, Alex > -----Original Message----- > From: > davinci-linux-open-source-bounces+alexr=vigilanttechnology.com > @linux.davincidsp.com > [mailto:davinci-linux-open-source-bounces+alexr=vigilanttechno [EMAIL PROTECTED] On Behalf Of davinci-linux-open-source-> [EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 22:47 > To: davinci-linux-open-source@linux.davincidsp.com > Subject: Davinci-linux-open-source Digest, Vol 13, Issue 44 > > Send Davinci-linux-open-source mailing list submissions to > davinci-linux-open-source@linux.davincidsp.com > > To subscribe or unsubscribe via the World Wide Web, visit > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Davinci-linux-open-source digest..." > > > Today's Topics: > > 1. Re: git tree updated to 2.6.20-rc5, plus misc updates > (Kevin Hilman) > 2. Re: Increasing HZ value in Linux kernel (Kevin Hilman) > 3. Re: Increasing HZ value in Linux kernel (David Brownell) > 4. Re: Increasing HZ value in Linux kernel (Kevin Hilman) > 5. Re: Can the DSP be a master besides being a slave in the CE > API (Andy Ngo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Jan 2007 10:27:58 -0800 > From: Kevin Hilman <[EMAIL PROTECTED]> > Subject: Re: git tree updated to 2.6.20-rc5, plus misc updates > To: davinci-linux-open-source@linux.davincidsp.com > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > On Tue, 2007-01-16 at 17:10 -0800, Kevin Hilman wrote: > > The git tree has been updated to 2.6.20-rc5. In addition to the > > upgrade, the following updates/fixes have been made: > [...] > > - USB updates from the MUSB driver in the OMAP tree > > I just pushed another update to fix compilation of the USB driver. > Also note, that the USB driver currently compiles when the > logging level > is > 0. This will be fixed shortly. > > See config option: > USB support --> Inventra High-Speed... --> Logging level > > Kevin > > > > > ------------------------------ > > Message: 2 > Date: Wed, 17 Jan 2007 11:43:20 -0800 > From: Kevin Hilman <[EMAIL PROTECTED]> > Subject: Re: Increasing HZ value in Linux kernel > To: Sander Huijsen <[EMAIL PROTECTED]> > Cc: davinci-linux-open-source@linux.davincidsp.com > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=utf-8 > > On Wed, 2007-01-17 at 05:03 -0500, Sander Huijsen wrote: > > > We wish to increase the HZ value in the Linux kernel from 100 (10ms > > period) to 1000 (1 ms period). > > It would be useful for you to explain _why_ you want to > change the timer > period. There are almost certainly much better ways to > achieve what you > want than globally changing the timer period. You will take a > significant performance hit in context switch overhead when > reducing the > timer period. > > You should strongly consider using the high-res timers instead. > > > I’ve changed the actual value of HZ in > include/asm-arm/param.h, but I > > don’t see any change: timer ticks are still 10ms. This > can be shown by > > running procinfo –n1 on the DVEVM and examining IRQ35, > which is the > > System Tick. Its value is increased with exactly 100 every second… > > > > As far as I can tell, the IRQ35 period is calculated in > > arch/arm/mach-davinci/time.c as: ((CLOCK_TICK_RATE / HZ) > – 1), where > > CLOCK_TICK_RATE equals 27MHz (hardware timer). > > That's correct. > > > Who can tell us what we need to do to increase the HZ as used in the > > kernel? > > This patch did it for me, although as I stated above, this is not > recommended. > > Index: linux-2.6.10/include/asm-arm/arch-davinci/param.h > =================================================================== > --- linux-2.6.10.orig/include/asm-arm/arch-davinci/param.h > +++ linux-2.6.10/include/asm-arm/arch-davinci/param.h > @@ -27,3 +27,6 @@ > * 675 Mass Ave, Cambridge, MA 02139, USA. > * > */ > + > +#define HZ 1000 > + > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 17 Jan 2007 11:59:19 -0800 > From: David Brownell <[EMAIL PROTECTED]> > Subject: Re: Increasing HZ value in Linux kernel > To: davinci-linux-open-source@linux.davincidsp.com > Cc: Sander Huijsen <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > On Wednesday 17 January 2007 11:43 am, Kevin Hilman wrote: > > On Wed, 2007-01-17 at 05:03 -0500, Sander Huijsen wrote: > > > > Who can tell us what we need to do to increase the HZ as > used in the > > > kernel? > > > > This patch did it for me, although as I stated above, this is not > > recommended. > > Best would be updating the "config HZ" entry in arch/arm/Kconfig... > from which all other values of HZ should derive. > > > > ------------------------------ > > Message: 4 > Date: Wed, 17 Jan 2007 12:11:32 -0800 > From: Kevin Hilman <[EMAIL PROTECTED]> > Subject: Re: Increasing HZ value in Linux kernel > To: David Brownell <[EMAIL PROTECTED]> > Cc: davinci-linux-open-source@linux.davincidsp.com, Sander Huijsen > <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > On Wed, 2007-01-17 at 11:59 -0800, David Brownell wrote: > > On Wednesday 17 January 2007 11:43 am, Kevin Hilman wrote: > > > On Wed, 2007-01-17 at 05:03 -0500, Sander Huijsen wrote: > > > > > > Who can tell us what we need to do to increase the HZ > as used in the > > > > kernel? > > > > > > This patch did it for me, although as I stated above, this is not > > > recommended. > > > > Best would be updating the "config HZ" entry in arch/arm/Kconfig... > > from which all other values of HZ should derive. > > This is true in the git kernel, but unfortunately, not in the MV > 2.6.10-based kernel. > > Kevin > > > > > ------------------------------ > > Message: 5 > Date: Wed, 17 Jan 2007 12:46:01 -0800 (PST) > From: Andy Ngo <[EMAIL PROTECTED]> > Subject: Re: Can the DSP be a master besides being a slave in the CE > API > To: "Ring, Chris" <[EMAIL PROTECTED]>, Jean-Michel Mercier > <[EMAIL PROTECTED]>, > davinci-linux-open-source@linux.davincidsp.com > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > In case anyone wants to know, I got my answer from TI that > the DSP can only be a slave when using the CE API and answers to a few > other questions I asked: > -------------------------------------------------------------- > ----------------------------------------------------- > Hi Andy, > > Here is the response I got back from our software support team > > "From a CE point of view the DSP is the server. There is not > a task that I know of that is running on the DSP that has > callback to the ARM. > > Multi-threaded applications must either serialize access to a > shared Engine instance or create a separate Engine instance > for each thread. Note: Be aware that Engine handles are not > thread-protected. Each thread that uses an Engine instance > should perform its own Engine_open call and use its own > Engine handle. This protects each Engine instance from access > by other threads in a multi-threaded environment." > > In conclusion, the answer to your first question is that no > DSP task calls on the ARM; after thinking about it a bit > more, even if you passed an ARM function pointer into the > DSP, in order for the DSP to call this ARM function, it would > have to do it via the RPC mechanism via which the ARM and the > DSP communicate. Unfortunately, this RPC mechanism appears > to be unidirectional (ARM to DSP) and to change it, you would > need codec engine source code which we do not give out. > > The answer to your second question is pretty clear from the > explanation above. > > Unfortunately, this is probably not what you wanted to hear > but hopefully these answers will help you make the right > decisions. Let us know if there is anything else we can > assist you with. > > Best Regards, > Juan Gonzales > > DSP Applications > Texas Instruments > Semiconductor Technical Support > http://www-k.ext.ti.com/sc/technical_support/pic/americas.htm > > If you have further questions please reply to this email. > And see the DSP Knowledge Base located at > http://www-k.ext.ti.com/sc/technical-support/knowledgebase.asp?dsp > > Also try the DSP Discussion Groups: A Place to Exchange Ideas > with Fellow DSP Developers located at > http://focus.ti.com/dsp/docs/dspsupporto.tsp?sectionId=3&tabId=413 > > TI assumes no liability for applications assistance or > customer product design. Customer is fully responsible for > all design decisions and engineering with regard to its > products, including decisions relating to application of TI > products. By providing technical information, TI does not > intend to offer or provide engineering services or advice > concerning Customer's design. If Customer desires engineering > services, the Customer should rely on its retained employees > and consultants and/or procure engineering services from a > licensed professional engineer (LPE). > > -----Original Message----- > > > Juan, > > Thanks for your response. I understood what you are saying > in answering question #3. I understand the basic idea behind > the codec framework and xDAIS/xDM compliant DSP algorithms. > The VISA / Code Engine API looks like a client-server API > where the ARM (the client, master) asks the DSP (the server, > slave) to process (encode/decode) data and return the > processed data to the ARM. However, what I was trying to ask > is: If we use the VISA / CE API, is there also a way for the > DSP to act as the master initiator and tells the ARM side > (now a slave) to do something? For example, I want to have a > task that runs under the DSP/BIOS within the CE Server on the > DSP side and want it to command the ARM side to do something. > So basically, I want to use the VISA / CE API method but > also want to expand it to make the DSP act as a master > requesting the ARM to process data also. If the VISA / CE > API doesnt allow that, does that mean I have to abandon VISA > / CE API method and come up > with my own xDAIS/xDM algorithm to do what I want (I rather > not because the VISA / CE API method is readily available for > use)? Please advise. Thank you. > > I would like to ask another question: When I create an > instance of a codec, (lets use the sphenc_copy codec as an > example, it has the SPHENCCOPY_TI_process and > SPHENCCOPY_TI_control functions), can different threads on > the ARM side call the different support functions of that > instance at the same time? For example, on the ARM > application, thread 1 calls SPHENCCOPY_TI_process but gets > interrupted by thread 2, which calls SPHENCCOPY_TI_control. > Will this cause a reentrant issue? Lets say those 2 > functions dont access come data on the DSP side. > > Thanks! > > > > ----- Original Message ---- > From: Andy Ngo <[EMAIL PROTECTED]> > To: "Ring, Chris" <[EMAIL PROTECTED]>; Jean-Michel Mercier > <[EMAIL PROTECTED]>; davinci-linux-open-source@linux.davincidsp.com > Sent: Monday, January 15, 2007 1:23:54 PM > Subject: Can the DSP be a master besides being a slave in the CE API > > > I figured out the smallest unit on the C64+ is a byte and > data can be aligned to non-even boundaries; I was asking > because I was using the C5510 last year and it was 16-bit > aligned only. > > On a different topic, (Chris/Jean-Michel, sorry for > addressing you directly, but you guys seem to be the most > experienced), can we do much stuff on the DSP side other than > it only being a encode/decode "slave" server to the ARM side > via the CE API? For example, can I implement a "master" > process/task under the DSP/BIOS OS on the DSP side and have > it initiate a intercommunication operation (across shared > memory) where the ARM (now a slave) is waiting for data? If > so, where do I find the documentation on how to do this? Thanks. > > Regards, > Andy Ngo > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://linux.omap.com/pipermail/davinci-linux-open-source/atta chments/20070117/70b1e68f/attachment.htm > > ------------------------------ > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > End of Davinci-linux-open-source Digest, Vol 13, Issue 44 > ********************************************************* > > This mail passed through VIGILANT TECHNOLOGY Mail-SeCure. > > ************************************************************** > ********************** > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, > vandals & computer viruses. > ************************************************************** > ********************** > This mail passed through VIGILANT TECHNOLOGY Mail-SeCure. ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
