From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755438AbdAFLMT (ORCPT ); Fri, 6 Jan 2017 06:12:19 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:55297 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755015AbdAFLLQ (ORCPT ); Fri, 6 Jan 2017 06:11:16 -0500 From: Arnd Bergmann To: Nikita Yushchenko Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , Catalin Marinas , linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Simon Horman , linux-pci@vger.kernel.org, Bjorn Helgaas , artemi.ivanov@cogentembedded.com Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Date: Fri, 06 Jan 2017 12:10:33 +0100 Message-ID: <2723285.JORgusvJv4@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <9d5e32d3-000c-2f95-7ea8-c64d53ab6b56@cogentembedded.com> References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <3158203.Yc9Qgx82xo@wuerfel> <9d5e32d3-000c-2f95-7ea8-c64d53ab6b56@cogentembedded.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:qCIUFkRv3l+dSj52ag32Gr/KFU1DZsFvKtZ4oZcBsmz1HLPjQHC QuFLVwPUp8Wg1BFWY1a7vMc8VbAGP92Evbaj4uVQlDWY/7QmGofRNXpCcxYw6ja0IKmMBzn Lz30BSG7CF7vOJaNvHfEl7lHmNqxZZ9kZGzEVmEZblimqz5Lg12LV4Bm7QccxsS9kF3jA08 jBAqg7WvD5rqV+WSqrfUQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:KsU0YUhgklI=:cBEUvU9ejcdz65MDBbB52I Zc2bP9mWB4CfTne0WAYarSDI6jaXgguHwlRkge8AoMPI9728WhoWu3tEjxg8T92vvJs9AnSPb onU213dqFPn3LTW8+GVPDQi9Q8IecRSpTeFT9Ir2UEYXqrL1s75sQNJJ2EgZoSo2fxwvIylLL Ke/8GGgDdYjf1orMPZm38DrZieKWDuzaOCV+ZqqvGR9uHwDdtTrkkOulbIgZw8n2l1d/PhRju nNaQ4yYfgiSvziktrE7WJ48b/jTTHAgdTKJIC0rcn4vCoUq1MvLLsjOmTxdaYKZhVNza30OyX uwsCYL7EroZKFaTGSolzNcbRalxO+4fY9sYcEnETobSss+xCbn+rvnQpO/28V5J1SgAMkEFhn ZdUpVzbZE7gTrluD6NUYdqs+vvZf85s/OCqj06+hK1kty2d9Dhi1Fjn9eLjTZkMIeODiEYNtg +vd1+5/pDanpf1WCtr6/WKv8e9w6XNR16FueHtfL5EhtTHrQw0Ojj7TpoM+DdYr1X8m9YL91s te3F6nsyl4o9anqvNLnlk+o9XQkf5JoWLDhIO0JwVNuY3bhHu/Kzf4VWleaXgrTG7BOMB5hHF iAfA2+nzCergvSv5MlqCw2GmjTBepxHYBk7M837aG9kLVZnsbUKCV8kR0dvi7y9nwISZ8BMTL 219xVjpQfQ+zpA72pjII/aXJv7co/vGsF1ozETWL/Yc2t48UZbfoMUHuOW5j922RlzTQUADtt 15soGORKk4C8UAbz Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, January 4, 2017 6:29:39 PM CET Nikita Yushchenko wrote: > > Just a guess, but if the inbound translation windows in the host > > bridge are wider than 32-bit, the reason for setting up a single > > 32-bit window is probably because that is what the parent bus supports. > > Well anyway applying patch similar to your's will fix pcie-rcar + nvme > case - thus I don't object :) But it can break other cases ... > > But why do you hook at set_dma_mask() and overwrite mask inside, instead > of hooking at dma_supported() and rejecting unsupported mask? > > I think later is better, because it lets drivers to handle unsupported > high-dma case, like documented in DMA-API_HOWTO. I think the behavior I put in there is required for swiotlb to make sense, otherwise you would rely on the driver to handle dma_set_mask() failure gracefully with its own bounce buffers (as network and scsi drivers do but others don't). Having swiotlb or iommu enabled should result in dma_set_mask() always succeeding unless the mask is too small to cover the swiotlb bounce buffer area or the iommu virtual address space. This behavior is particularly important in case the bus address space is narrower than 32-bit, as we have to guarantee that the fallback to 32-bit DMA always succeeds. There are also a lot of drivers that try to set a 64-bit mask but don't implement bounce buffers for streaming mappings if that fails, and swiotlb is what we use to make those drivers work. And yes, the API is a horrible mess. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: From: Arnd Bergmann To: Nikita Yushchenko Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Date: Fri, 06 Jan 2017 12:10:33 +0100 Message-ID: <2723285.JORgusvJv4@wuerfel> In-Reply-To: <9d5e32d3-000c-2f95-7ea8-c64d53ab6b56@cogentembedded.com> References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <3158203.Yc9Qgx82xo@wuerfel> <9d5e32d3-000c-2f95-7ea8-c64d53ab6b56@cogentembedded.com> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Simon Horman , linux-pci@vger.kernel.org, Bjorn Helgaas , artemi.ivanov@cogentembedded.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+bjorn=helgaas.com@lists.infradead.org List-ID: On Wednesday, January 4, 2017 6:29:39 PM CET Nikita Yushchenko wrote: > > Just a guess, but if the inbound translation windows in the host > > bridge are wider than 32-bit, the reason for setting up a single > > 32-bit window is probably because that is what the parent bus supports. > > Well anyway applying patch similar to your's will fix pcie-rcar + nvme > case - thus I don't object :) But it can break other cases ... > > But why do you hook at set_dma_mask() and overwrite mask inside, instead > of hooking at dma_supported() and rejecting unsupported mask? > > I think later is better, because it lets drivers to handle unsupported > high-dma case, like documented in DMA-API_HOWTO. I think the behavior I put in there is required for swiotlb to make sense, otherwise you would rely on the driver to handle dma_set_mask() failure gracefully with its own bounce buffers (as network and scsi drivers do but others don't). Having swiotlb or iommu enabled should result in dma_set_mask() always succeeding unless the mask is too small to cover the swiotlb bounce buffer area or the iommu virtual address space. This behavior is particularly important in case the bus address space is narrower than 32-bit, as we have to guarantee that the fallback to 32-bit DMA always succeeds. There are also a lot of drivers that try to set a 64-bit mask but don't implement bounce buffers for streaming mappings if that fails, and swiotlb is what we use to make those drivers work. And yes, the API is a horrible mess. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Fri, 06 Jan 2017 12:10:33 +0100 Subject: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask In-Reply-To: <9d5e32d3-000c-2f95-7ea8-c64d53ab6b56@cogentembedded.com> References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <3158203.Yc9Qgx82xo@wuerfel> <9d5e32d3-000c-2f95-7ea8-c64d53ab6b56@cogentembedded.com> Message-ID: <2723285.JORgusvJv4@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday, January 4, 2017 6:29:39 PM CET Nikita Yushchenko wrote: > > Just a guess, but if the inbound translation windows in the host > > bridge are wider than 32-bit, the reason for setting up a single > > 32-bit window is probably because that is what the parent bus supports. > > Well anyway applying patch similar to your's will fix pcie-rcar + nvme > case - thus I don't object :) But it can break other cases ... > > But why do you hook at set_dma_mask() and overwrite mask inside, instead > of hooking at dma_supported() and rejecting unsupported mask? > > I think later is better, because it lets drivers to handle unsupported > high-dma case, like documented in DMA-API_HOWTO. I think the behavior I put in there is required for swiotlb to make sense, otherwise you would rely on the driver to handle dma_set_mask() failure gracefully with its own bounce buffers (as network and scsi drivers do but others don't). Having swiotlb or iommu enabled should result in dma_set_mask() always succeeding unless the mask is too small to cover the swiotlb bounce buffer area or the iommu virtual address space. This behavior is particularly important in case the bus address space is narrower than 32-bit, as we have to guarantee that the fallback to 32-bit DMA always succeeds. There are also a lot of drivers that try to set a 64-bit mask but don't implement bounce buffers for streaming mappings if that fails, and swiotlb is what we use to make those drivers work. And yes, the API is a horrible mess. Arnd