Felipe, > -----Original Message----- > From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx] > Sent: Friday, March 20, 2009 3:48 PM > To: Hiroshi DOYU > Cc: Gupta, Ramesh; Kanigeri, Hari; Guzman Lugo, Fernando; > linux-omap@xxxxxxxxxxxxxxx; ameya.palande@xxxxxxxxx > Subject: Re: [PATCH B 3/3] tidspbridge: decreate timeout to a > saner value > > On Fri, Mar 20, 2009 at 9:36 AM, Hiroshi DOYU > <Hiroshi.DOYU@xxxxxxxxx> wrote: > > From: Hiroshi DOYU <Hiroshi.DOYU@xxxxxxxxx> > > Subject: Re: [PATCH B 3/3] tidspbridge: decreate timeout to a saner > > value > > Date: Fri, 20 Mar 2009 06:54:04 +0200 (EET) > > > >> From: ext Felipe Contreras <felipe.contreras@xxxxxxxxx> > >> Subject: Re: [PATCH B 3/3] tidspbridge: decreate timeout > to a saner > >> value > >> Date: Fri, 20 Mar 2009 01:06:16 +0100 > >> > >> > On Fri, Mar 20, 2009 at 2:00 AM, Guzman Lugo, Fernando > <x0095840@xxxxxx> wrote: > >> > > > >> > > > >> > > > >> > > This is a stress test, it creates 4 processes and each > process will do 1000 transfers using streams, so the trace is: > >> > > > >> > > STRM_Issue -> WMD_CHNL_AddIOReq -> IO_Schedule > >> > > > >> > > IO_Schedule schedules a call to IO_DPC using task let. > >> > > > >> > > IO_DPC -> IO_DispatchChnl -> InputChnl -> CHNLSM_InterruptDSP2 > >> > > > >> > > Also IO_DispatchChnl -> OutputChnl -> > CHNLSM_InterruptDSP2. > >> > > > >> > > > >> > > As we can call a lot CHNLSM_InterruptDSP2 in this > test, there is a problem with the timeout. However running > other tests, videos and mp3 there no problems. I think we > should change to 10ms, only to make sure there is no problem > when CHNLSM_InterruptDSP2 is called a lot. > >> > > > >> > > Let me know if you are agreed. Or have some comments about it. > >> > > >> > Well again, the best way to implement the wait for a slot in the > >> > mailbox is with interrupts, not busy-looping. If we > busy-loop too > >> > much that would increase the CPU usage, and that would be bad. > >> > >> I think that s/w queuing of messages would be more > efficient to allow > >> multiple senders to continue thier work anyway, especially in the > >> case of having these streamings. > > > > Migrating to the existing mailbox driver("plat-omap/mailbox.c") is > > also another option to support multiple OMAP architectures > at the same > > time. That mailbox driver has already had a message queuing feature > > inside and it's buildable on OMAP3. > > Yeap, I have it in my to-do list, so if somebody doesn't beat > me to it I play with that. We already started looking into this :), made some progress, will provide more updates in a day or two. Regards Ramesh Gupta G -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
