From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id B34E7B716E for ; Sat, 13 Jun 2009 00:01:34 +1000 (EST) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 0E299DDD04 for ; Sat, 13 Jun 2009 00:01:33 +1000 (EST) Message-Id: <718B5524-9FB1-4835-BAEA-C5B990F78DAC@kernel.crashing.org> From: Kumar Gala To: Li Yang In-Reply-To: <2a27d3730906120627l112030b3wa11ea5aa3fcb1087@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access Date: Fri, 12 Jun 2009 08:58:49 -0500 References: <1242117363-14949-1-git-send-email-leoli@freescale.com> <90AED712-28A1-4800-978C-125A887D0DA7@kernel.crashing.org> <3A45394FD742FA419B760BB8D398F9ED483CCD@zch01exm26.fsl.freescale.net> <5D8775BD-9973-4DE8-B442-91FB15F86ACC@kernel.crashing.org> <2a27d3730906120627l112030b3wa11ea5aa3fcb1087@mail.gmail.com> Cc: Zhang Wei , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, davem@davemloft.net, linuxppc-dev@ozlabs.org, akpm@linux-foundation.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Jun 12, 2009, at 8:27 AM, Li Yang wrote: > On Thu, Jun 11, 2009 at 9:32 PM, Kumar > Gala wrote: >> >> On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote: >> >>>> On May 12, 2009, at 3:35 AM, Li Yang wrote: >>>> >>>>> Add the mapping functions used to support direct IO memory >>>>> access of >>>>> rapidIO. >>>>> >>>>> Signed-off-by: Zhang Wei >>>>> Signed-off-by: Li Yang >>>> >>>> Use inbnd/outbnd instead of inb/outb which make one think of >>>> byte level io accessors. >>>> >>>> As I look at this I don't think this is the correct API. I >>>> think we should be using the DMA mapping API to hide these >>>> details. The concept of mapping like this seems to be more a >>>> function of FSL's Address translation/mapping unit (ATMU) than >>>> anything specific to the RIO bus standard. >>> >>> This is a separate RIO block level ATMU. Although it looks like the >>> system level ATMU, system ATMU doesn't have the knowledge of rapidIO >>> target device ID. The mapping need to be dynamic, as it's easy to >>> have >>> more RIO devices than the outbound windows. >> >> I understand that. What I'm saying is the RIO block level ATMU is a >> Freescale specific detail and not part of any standard RIO bus >> programming >> model. We have mapping APIs that we can connect to for this via >> the DMA API >> layer. > > Ok, I see your point now. Do you mean dma_map_*() for DMA API layer? > But in my understanding the current dma_map_*() APIs are preparing > local memory for device to access which is similar to the inbound > case. Is it suitable to also use them for mapping device's space for > CPU access? Can you give an example of using this API for Address > Translation and Mapping purpose? Yes, I meant the dma_map_*() API. Any system with a true IOMMU uses the dma_map_ layer as the way to do address translation. - k