RE: [RFC] Port TI DSP BRIDGE for a new dedicated branch in linux-omap

2008-08-15 Thread Pasam, Vijay
: Friday, August 15, 2008 4:10 PM To: Woodruff, Richard Cc: Tony Lindgren; Hiroshi DOYU; linux-omap@vger.kernel.org; [EMAIL PROTECTED]; Kanigeri, Hari; Ramirez Luna, Omar; Gupta, Ramesh; [EMAIL PROTECTED]; Pasam, Vijay Subject: Re: [RFC] Port TI DSP BRIDGE for a new dedicated branch in linux

RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge

2008-06-09 Thread Pasam, Vijay
Does DSP use virtual-to-physical mapping for all the addresses it accesses (including DSP's local buffers)? Or it uses this mapping only to access shared buffers? Wont it be a big overhead if DSP accesses all the memories through virtual-to-physical mapping? DSP has to access all the

RE: OMAP3 DSPBridge review

2008-04-17 Thread Pasam, Vijay
Hi Trilok: TI has to decide, what path they have to follow now onwards for bridge, I see no need of OSAL layer, when we are targeting this as Linux kernel driver. We are investigating the effort required to do this. We will get back on this. Thanks for the pointer on the

RE: OMAP3 DSPBridge GIT tree?

2008-04-16 Thread Pasam, Vijay
Hi Trilok: We are internally working on moving the source code to GIT tree. We are investigating various options in this regard. I will let you know more details as we conclude on various options. Best Regards Vijay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On

RE: OMAP3 DSPBridge review

2008-04-16 Thread Pasam, Vijay
Hi Trilok: I was just going this dspbridge code, and I was surprised to find layers for un-necessary things, where we could have simply called the linux kernel provided function. Here goes the list: 1. There is un-necessary linux directory inside mpu_driver source codes. e.g