From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752085Ab0JTJ1H (ORCPT ); Wed, 20 Oct 2010 05:27:07 -0400 Received: from smtp.nokia.com ([192.100.105.134]:65351 "EHLO mgw-mx09.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750891Ab0JTJ1F (ORCPT ); Wed, 20 Oct 2010 05:27:05 -0400 Date: Wed, 20 Oct 2010 12:26:38 +0300 (EEST) Message-Id: <20101020.122638.112626316.Hiroshi.DOYU@nokia.com> To: felipe.contreras@gmail.com Cc: x0095840@ti.com, felipe.contreras@nokia.com, david.cohen@nokia.com, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range From: Hiroshi DOYU In-Reply-To: References: <20101020.114516.189725260.Hiroshi.DOYU@nokia.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2010 09:26:44.0836 (UTC) FILETIME=[E9833240:01CB7038] X-Nokia-AV: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: ext Felipe Contreras Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range Date: Wed, 20 Oct 2010 10:58:16 +0200 > On Wed, Oct 20, 2010 at 11:45 AM, Hiroshi DOYU wrote: >> From: "ext felipe.contreras@gmail.com" >> Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range >> Date: Wed, 20 Oct 2010 10:35:50 +0200 >> >>> On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo wrote: >>>> Some IOMMUs cannot use the whole 0x0 - 0xFFFFFFFF range. >>>> With this new API the valid range can be set. >>>> >>>> Signed-off-by: Fernando Guzman Lugo >>> >>> I don't see the point in having an API. It could be done through >>> platform data, and the usage of 0xFFFFF000 instead of ULONG_MAX is >>> independent of this. >> >> Using platform data is better, but why dropping da_end? > > Because it's always 0xFFFFF000. Do you know of any instance where >it's not? We should try to avoid forcing unnecessary limitations and dependencies. The usage of device virtual address space range depends on dsp(coprocessor) side S/W implimentation or configuration.