From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ohad Ben-Cohen Subject: Re: [Linaro-mm-sig] [PATCH 2/2] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver Date: Tue, 6 Sep 2011 15:35:48 +0300 Message-ID: References: <1314971786-15140-1-git-send-email-m.szyprowski@samsung.com> <1314971786-15140-3-git-send-email-m.szyprowski@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org To: KyongHo Cho Cc: Marek Szyprowski , linux-arch@vger.kernel.org, Kukjin Kim , Russell King - ARM Linux , Arnd Bergmann , Joerg Roedel , linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, Kyungmin Park , Linux Samsung SOC , Andrzej Pietrasiewicz , Chunsang Jeong , linux-arm-kernel@lists.infradead.org List-Id: linux-arch.vger.kernel.org On Tue, Sep 6, 2011 at 1:27 PM, KyongHo Cho wrote: > On Fri, Sep 2, 2011 at 10:56 PM, Marek Szyprowski >> +static int s5p_sysmmu_map(struct iommu_domain *domain, unsigned long io= va, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 phys_addr_t paddr, int= gfp_order, int prot) >> +{ >> + =A0 =A0 =A0 struct s5p_sysmmu_domain *s5p_domain =3D domain->priv; >> + =A0 =A0 =A0 int flpt_idx =3D flpt_index(iova); >> + =A0 =A0 =A0 size_t len =3D 0x1000UL << gfp_order; >> + =A0 =A0 =A0 void *flpt_va, *slpt_va; >> + >> + =A0 =A0 =A0 if (len !=3D SZ_16M && len !=3D SZ_1M && len !=3D SZ_64K &= & len !=3D SZ_4K) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 sysmmu_debug(3, "bad order: %d\n", gfp_ord= er); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL; >> + =A0 =A0 =A0 } > > Likewise, I think this driver need to support mapping 128KiB aligned, > 128KiB physical memory, for example. > > Otherwise, it is somewhat restrictive than we expect. That's actually OK, because the IOMMU core will split physically contiguous memory regions to pages on behalf of its drivers (drivers will just have to advertise the page sizes their hardware supports); this way you don't duplicate the logic in every IOMMU driver. Take a look: http://www.spinics.net/lists/linux-omap/msg56660.html -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:61042 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753552Ab1IFMgJ convert rfc822-to-8bit (ORCPT ); Tue, 6 Sep 2011 08:36:09 -0400 MIME-Version: 1.0 In-Reply-To: References: <1314971786-15140-1-git-send-email-m.szyprowski@samsung.com> <1314971786-15140-3-git-send-email-m.szyprowski@samsung.com> From: Ohad Ben-Cohen Date: Tue, 6 Sep 2011 15:35:48 +0300 Message-ID: Subject: Re: [Linaro-mm-sig] [PATCH 2/2] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-arch-owner@vger.kernel.org List-ID: To: KyongHo Cho Cc: Marek Szyprowski , linux-arch@vger.kernel.org, Kukjin Kim , Russell King - ARM Linux , Arnd Bergmann , Joerg Roedel , linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, Kyungmin Park , Linux Samsung SOC , Andrzej Pietrasiewicz , Chunsang Jeong , linux-arm-kernel@lists.infradead.org Message-ID: <20110906123548.tmFvVsp7TFodF06N1gbQkN7RRCKj0FY1kpTo8oIYdVQ@z> On Tue, Sep 6, 2011 at 1:27 PM, KyongHo Cho wrote: > On Fri, Sep 2, 2011 at 10:56 PM, Marek Szyprowski >> +static int s5p_sysmmu_map(struct iommu_domain *domain, unsigned long iova, >> +                         phys_addr_t paddr, int gfp_order, int prot) >> +{ >> +       struct s5p_sysmmu_domain *s5p_domain = domain->priv; >> +       int flpt_idx = flpt_index(iova); >> +       size_t len = 0x1000UL << gfp_order; >> +       void *flpt_va, *slpt_va; >> + >> +       if (len != SZ_16M && len != SZ_1M && len != SZ_64K && len != SZ_4K) { >> +               sysmmu_debug(3, "bad order: %d\n", gfp_order); >> +               return -EINVAL; >> +       } > > Likewise, I think this driver need to support mapping 128KiB aligned, > 128KiB physical memory, for example. > > Otherwise, it is somewhat restrictive than we expect. That's actually OK, because the IOMMU core will split physically contiguous memory regions to pages on behalf of its drivers (drivers will just have to advertise the page sizes their hardware supports); this way you don't duplicate the logic in every IOMMU driver. Take a look: http://www.spinics.net/lists/linux-omap/msg56660.html