From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver Date: Tue, 19 Apr 2011 16:29:49 +0200 Message-ID: <201104191629.49676.arnd@arndb.de> References: <1303118804-5575-1-git-send-email-m.szyprowski@samsung.com> <201104191449.50824.arnd@arndb.de> <000001cbfe9a$8e64cae0$ab2e60a0$%szyprowski@samsung.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from moutng.kundenserver.de ([212.227.17.10]:64065 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752607Ab1DSO3z (ORCPT ); Tue, 19 Apr 2011 10:29:55 -0400 In-Reply-To: <000001cbfe9a$8e64cae0$ab2e60a0$%szyprowski@samsung.com> Sender: linux-samsung-soc-owner@vger.kernel.org List-Id: linux-samsung-soc@vger.kernel.org To: Marek Szyprowski Cc: 'Joerg Roedel' , linux-samsung-soc@vger.kernel.org, 'Kyungmin Park' , 'Kukjin Kim' , 'Sylwester Nawrocki' , 'Andrzej Pietrasiewicz' , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org On Tuesday 19 April 2011, Marek Szyprowski wrote: > > > > 1. change the runtime_pm subsystem to allow it to ignore some devices > > in an easy way. > > > > 2. change the device layout if the sysmmu. If the iommu device is > > a child of the device that it is responsible for, I guess you don't > > have this problem. > > > > 3. Not represent the iommu as a device at all, just as a property > > of another device. > > Ok, we will handle this issue somehow. I consider this a minor issue and I > would like to focus on the IOMMU/dma-mapping APIs first. Yes, agreed. > > That is a limitation of the current implementation. We might want to > > change that anyway, e.g. to handle the mali IOMMU along with yours. > > I believe the reason for allowing only one IOMMU type so far has been > > that nobody required more than one. As I mentioned, the IOMMU API is > > rather new and has not been ported to much variety of hardware, unlike > > the dma-mapping API, which does support multiple different IOMMUs > > in a single system. > > Ok. I understand. IOMMU API is quite nice abstraction of the IOMMU chip. > dma-mapping API is something much more complex that creates the actual > mapping for various sets of the devices. IMHO the right direction will > be to create dma-mapping implementation that will be just a client of > the IOMMU API. What's your opinion? Sounds good. I think we should put it into a new drivers/iommu, along with your specific iommu implementation, and then we can convert the existing ones over to use that. Note that this also requires using dma-mapping-common.h, which we currently don't on ARM. > > The domain really reflects the user, not the device here, which makes more > > sense if you think of virtual machines than of multimedia devices. > > > > I would suggest that you just use a single iommu_domain globally for > > all in-kernel users. > > There are cases where having a separate mapping for each device makes sense. > It definitely increases the security and helps to find some bugs in > the drivers. > > Getting back to our video codec - it has 2 IOMMU controllers. The codec > hardware is able to address only 256MiB of space. Do you have an idea how > this can be handled with dma-mapping API? The only idea that comes to my > mind is to provide a second, fake 'struct device' and use it for allocations > for the second IOMMU controller. Good question. How do you even decide which controller to use from the driver? I would need to understand better what you are trying to do to give a good recommendation. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 19 Apr 2011 16:29:49 +0200 Subject: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver In-Reply-To: <000001cbfe9a$8e64cae0$ab2e60a0$%szyprowski@samsung.com> References: <1303118804-5575-1-git-send-email-m.szyprowski@samsung.com> <201104191449.50824.arnd@arndb.de> <000001cbfe9a$8e64cae0$ab2e60a0$%szyprowski@samsung.com> Message-ID: <201104191629.49676.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 19 April 2011, Marek Szyprowski wrote: > > > > 1. change the runtime_pm subsystem to allow it to ignore some devices > > in an easy way. > > > > 2. change the device layout if the sysmmu. If the iommu device is > > a child of the device that it is responsible for, I guess you don't > > have this problem. > > > > 3. Not represent the iommu as a device at all, just as a property > > of another device. > > Ok, we will handle this issue somehow. I consider this a minor issue and I > would like to focus on the IOMMU/dma-mapping APIs first. Yes, agreed. > > That is a limitation of the current implementation. We might want to > > change that anyway, e.g. to handle the mali IOMMU along with yours. > > I believe the reason for allowing only one IOMMU type so far has been > > that nobody required more than one. As I mentioned, the IOMMU API is > > rather new and has not been ported to much variety of hardware, unlike > > the dma-mapping API, which does support multiple different IOMMUs > > in a single system. > > Ok. I understand. IOMMU API is quite nice abstraction of the IOMMU chip. > dma-mapping API is something much more complex that creates the actual > mapping for various sets of the devices. IMHO the right direction will > be to create dma-mapping implementation that will be just a client of > the IOMMU API. What's your opinion? Sounds good. I think we should put it into a new drivers/iommu, along with your specific iommu implementation, and then we can convert the existing ones over to use that. Note that this also requires using dma-mapping-common.h, which we currently don't on ARM. > > The domain really reflects the user, not the device here, which makes more > > sense if you think of virtual machines than of multimedia devices. > > > > I would suggest that you just use a single iommu_domain globally for > > all in-kernel users. > > There are cases where having a separate mapping for each device makes sense. > It definitely increases the security and helps to find some bugs in > the drivers. > > Getting back to our video codec - it has 2 IOMMU controllers. The codec > hardware is able to address only 256MiB of space. Do you have an idea how > this can be handled with dma-mapping API? The only idea that comes to my > mind is to provide a second, fake 'struct device' and use it for allocations > for the second IOMMU controller. Good question. How do you even decide which controller to use from the driver? I would need to understand better what you are trying to do to give a good recommendation. Arnd