Message ID | 1299615316-17512-3-git-send-email-dacohen@gmail.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers |
Return-path: <mchehab@pedra> Envelope-to: mchehab@pedra Delivery-date: Tue, 08 Mar 2011 17:16:57 -0300 Received: from mchehab by pedra with local (Exim 4.72) (envelope-from <mchehab@pedra>) id 1Px3Kz-0000mw-5C for mchehab@pedra; Tue, 08 Mar 2011 17:16:57 -0300 Received: from casper.infradead.org [85.118.1.10] by pedra with IMAP (fetchmail-6.3.17) for <mchehab@localhost> (single-drop); Tue, 08 Mar 2011 17:16:57 -0300 (BRT) Received: from vger.kernel.org ([209.132.180.67]) by casper.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1Px3Jk-0004MZ-1S; Tue, 08 Mar 2011 20:15:40 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755784Ab1CHUPh (ORCPT <rfc822; kmpark@infradead.org> + 1 other); Tue, 8 Mar 2011 15:15:37 -0500 Received: from mail-ey0-f174.google.com ([209.85.215.174]:48929 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756090Ab1CHUPf (ORCPT <rfc822; linux-media@vger.kernel.org>); Tue, 8 Mar 2011 15:15:35 -0500 Received: by mail-ey0-f174.google.com with SMTP id 24so2180490eyx.19 for <multiple recipients>; Tue, 08 Mar 2011 12:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:date:message-id:x-mailer :in-reply-to:references; bh=fNAVzewxzl8CUadkSgxlhdjuZMMLpPXSLv2oEJSFpdA=; b=V2vaJJg04eD27MMWbk8JkHG7HsNfeUTehHV3aYwPAtTKZmvnkzb0fuN+vf3a8ePpQ6 RdGM+cquu8POOaiWIOeXZ2qkP9XhkVknHyA6XfsQ3Fr4TVm4uzukrs8mx9GnfCzIg18x vT1o89y8r2PChxNgPZzOvSt2czxQdgYrxtyT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; b=wq6i1G5w9O+SZsbONrhxpLjjIulwI0x985Lr3CxFcHlwy1FH5ybJJVSw1SV04wIrfy EmgjPH32qmexdoCUX3kRPJYTyo6Dk/t/O9QvKrdgwDSp0xRdD4qu9TB4kWhd3CGnaYI4 thCJwYWEzDuU1UEv+JE2RHysdEsSNnxqiaEzM= Received: by 10.213.19.132 with SMTP id a4mr3092726ebb.4.1299615335041; Tue, 08 Mar 2011 12:15:35 -0800 (PST) Received: from localhost.localdomain (a91-152-69-14.elisa-laajakaista.fi [91.152.69.14]) by mx.google.com with ESMTPS id x54sm931448eeh.5.2011.03.08.12.15.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2011 12:15:31 -0800 (PST) From: David Cohen <dacohen@gmail.com> To: Hiroshi.DOYU@nokia.com Cc: linux-omap@vger.kernel.org, fernando.lugo@ti.com, linux-media@vger.kernel.org, laurent.pinchart@ideasonboard.com, sakari.ailus@maxwell.research.nokia.com, David Cohen <dacohen@gmail.com> Subject: [PATCH v2 2/3] omap3: change ISP's IOMMU da_start address Date: Tue, 8 Mar 2011 22:15:15 +0200 Message-Id: <1299615316-17512-3-git-send-email-dacohen@gmail.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: <1299615316-17512-1-git-send-email-dacohen@gmail.com> References: <1299615316-17512-1-git-send-email-dacohen@gmail.com> Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org Sender: <mchehab@pedra> |
Commit Message
David Cohen
March 8, 2011, 8:15 p.m. UTC
ISP doesn't consider 0x0 as a valid address, so it should explicitly
exclude first page from allowed 'da' range.
Signed-off-by: David Cohen <dacohen@gmail.com>
---
arch/arm/mach-omap2/omap-iommu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Comments
David Cohen wrote: > ISP doesn't consider 0x0 as a valid address, so it should explicitly > exclude first page from allowed 'da' range. > > Signed-off-by: David Cohen <dacohen@gmail.com> > --- > arch/arm/mach-omap2/omap-iommu.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c > index 3fc5dc7..3bea489 100644 > --- a/arch/arm/mach-omap2/omap-iommu.c > +++ b/arch/arm/mach-omap2/omap-iommu.c > @@ -33,7 +33,7 @@ static struct iommu_device omap3_devices[] = { > .name = "isp", > .nr_tlb_entries = 8, > .clk_name = "cam_ick", > - .da_start = 0x0, > + .da_start = 0x1000, > .da_end = 0xFFFFF000, > }, > }, Hi David! Thanks for the patch. My question is once again: is this necessary? My understanding is that the IOMMU allows mapping the NULL address if the user wishes to map it explicitly. da_end specifies the real hardware limit for the mapped top address, da_start should do the same for bottom. I think that the IOMMU users should be either able to rely that they get no NULL allocated automatically for them. Do we want or not want it to be part of the API? I don't think the ISP driver is a special case of all the possible drivers using the IOMMU. On the other hand, probably there will be an API change at some point for the IOMMU since as far as I remember, there are somewhat established APIs for IOMMUs in existence. Regards,
On Wed, Mar 9, 2011 at 9:43 AM, Sakari Ailus <sakari.ailus@maxwell.research.nokia.com> wrote: > David Cohen wrote: >> ISP doesn't consider 0x0 as a valid address, so it should explicitly >> exclude first page from allowed 'da' range. >> >> Signed-off-by: David Cohen <dacohen@gmail.com> >> --- >> arch/arm/mach-omap2/omap-iommu.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c >> index 3fc5dc7..3bea489 100644 >> --- a/arch/arm/mach-omap2/omap-iommu.c >> +++ b/arch/arm/mach-omap2/omap-iommu.c >> @@ -33,7 +33,7 @@ static struct iommu_device omap3_devices[] = { >> .name = "isp", >> .nr_tlb_entries = 8, >> .clk_name = "cam_ick", >> - .da_start = 0x0, >> + .da_start = 0x1000, >> .da_end = 0xFFFFF000, >> }, >> }, > > Hi David! Hi Sakari, > > Thanks for the patch. And thanks for the comments. :) > > My question is once again: is this necessary? My understanding is that > the IOMMU allows mapping the NULL address if the user wishes to map it > explicitly. da_end specifies the real hardware limit for the mapped top > address, da_start should do the same for bottom. Hm. da_start/da_end in this case belong to OMAP3 IOMMU ISP VM. It means they're related to OMAP3 ISP only. But they do not reflect the hw limit, as the range limit is anything which fits in u32. They say what's the range OMAP3 ISP is expecting to have mapped. And the answer to this question is the first page is not expected. Then, why say the opposite in da_start? > > I think that the IOMMU users should be either able to rely that they get > no NULL allocated automatically for them. Do we want or not want it to > be part of the API? I don't think the ISP driver is a special case of > all the possible drivers using the IOMMU. My understanding after this discussion is address 0x0 should be allowed (what is done by patch 3/3 of this set). But as a safer choice, it won't be returned without explicitly request (what is done in path 1/3). Because of that, I'm OK in drop this patch 2/3. But then there's one question which is the motivation for this change: If the current OMAP3 ISP driver doesn't want the first page, (1) should we pass a generic information and expect IOVMM driver to correct it to ISP need or (2) should we pass the information which reflects the real ISP driver's need? My understanding is (2). But I'm fine with (1) as it will lead to the same result. > > On the other hand, probably there will be an API change at some point > for the IOMMU since as far as I remember, there are somewhat > established APIs for IOMMUs in existence. At some point we need to find a standard for many IOMMU drivers. But for now we need to stick with what we have. :) Regards, David Cohen -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c index 3fc5dc7..3bea489 100644 --- a/arch/arm/mach-omap2/omap-iommu.c +++ b/arch/arm/mach-omap2/omap-iommu.c @@ -33,7 +33,7 @@ static struct iommu_device omap3_devices[] = { .name = "isp", .nr_tlb_entries = 8, .clk_name = "cam_ick", - .da_start = 0x0, + .da_start = 0x1000, .da_end = 0xFFFFF000, }, },