From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765236AbcINVvT (ORCPT ); Wed, 14 Sep 2016 17:51:19 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:52459 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753427AbcINVvS (ORCPT ); Wed, 14 Sep 2016 17:51:18 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Lorenzo Pieralisi , Felipe Balbi , Grygorii Strashko , Russell King - ARM Linux , Catalin Marinas , Yoshihiro Shimoda , "linux-usb@vger.kernel.org" , Sekhar Nori , lkml , Stuart Yoder , Scott Wood , David Fisher , "Thang Q. Nguyen" , Leo Li , Greg Kroah-Hartman , Alan Stern , Robin Murphy , Peter Chen Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Date: Wed, 14 Sep 2016 23:50:20 +0200 Message-ID: <5948102.1fQRRodOXz@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160914163136.GA26842@red-moon> References: <874m5skmv9.fsf@linux.intel.com> <20160914163136.GA26842@red-moon> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:PGY5T/eLR13/mp4fsFjublB7ewuxfl252gvLmcTTqPz/1ZEBWzK MuGNGe7hAY+ib7oqau9CjDJF+VJKBvT+Zl//Q72jZVcghOJl+hsMII2syK/VZOkU7jUTBT4 3DVXHpCHl9Sdwhin6xc1biPEYCCB5852ysZ3DYVcA7DMQ5I18VztLas3qvbKDN3VPudVDyo E2n4RrCXvt2q/4i08vPxw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SLiRisAfuls=:6XMUvf/IcGIRLfnYm7EulQ Ds3RJcI7MKtXxuuntNDUwTXdsLXALmLo4NqkVgcTVJbymtpM4lTw/A5ZI57ULe6+d1FvNieou VRFmTa7hnHIObaY8pvSxFVKUXUcUOvqcaY0gJs03e7d1wpHPps6bcZlfBrTvz/hHpOI5R+9/W K8CAZhYrOzuc9FP01sfqC/skCEUQ4bh28ejLk3Y0IaQduuBQotJXNzL5V6HLK3s9Ly+/8/acp z134b+91JtGyu6F7B+UqZGJO+zAsUM5UZp0zfSNmguo8Z5hq+vMhN+Ye+uGfwITpFc6uMs25+ dj0ngleDnKkzjwPBkU6p4TndEFEl2ZLZSHsq1TzKPOOxWx3fK9r9f1TzchjHjNkuTBhe8ze3G oCvw4svXa8HLq0+FfHBXtI8i/+4IC/EFmLTRT10DBA4iWgAQ3/HtmZU7B82v+qFaB7TJCkamO iTLsc3orFXl4O6AC3EZ1kwLWzwb+sasCl9fvAdH+cGPF48GOvYOFyEgBn3XWpH4TjMT2tzSsX R1VnjxRhhbMuU+W5QRUCm01PZrGey/5BPKUXSF+tGan31eDgyh8uy/fYyrnbMG0A7cBswwFCM vqZ5P34TJ2qUhfQGSYtqpJN+LCB+OPl/jhr0ev3NNSbmBSW5vXyN4efT8l3hGoxQHfpECvugl BdStd5a9Tht1CcXhhE4qZwVbA0aJKm3zVcArWiEwuwNB5SshnfBdJmlEEsr8VE3J275QxcWgf juJMujX25SFbJp9G Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, September 14, 2016 5:31:36 PM CEST Lorenzo Pieralisi wrote: > On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote: > > > > Hi, > > > > Robin Murphy writes: > > > On 07/09/16 10:55, Peter Chen wrote: > > > [...] > > >>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(), > > >>> I think we should replace > > >>> > > >>> pdev->dev.dma_mask = dev->dma_mask; > > >>> pdev->dev.dma_parms = dev->dma_parms; > > >>> dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask); > > >>> > > >>> with of_dma_configure(), which has the chance to configure more than > > >>> just those three, as the dma API might look into different aspects: > > >>> > > >>> - iommu specific configuration > > >>> - cache coherency information > > >>> - bus type > > >>> - dma offset > > >>> - dma_map_ops pointer > > >>> > > >>> We try to handle everything in of_dma_configure() at configuration > > >>> time, and that would be the place to add anything else that we might > > >>> need in the future. > > >>> > > >> > > >> Yes, I agree with you, but just like Felipe mentioned, we also need to > > >> consider PCI device, can we do something like gpiod_get_index does? Are > > >> there any similar APIs like of_dma_configure for ACPI? > > > > > > Not yet, but Lorenzo has one in progress[1], primarily for the sake of > > > abstracting away the IOMMU configuration. > > > > > > Robin. > > > > > > [1]:http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1209911.html > > > > not exported for drivers to use. If Lorenzo is trying to making a > > matching API for ACPI systems, then it needs to follow what > > of_dma_configure() is doing, and add an EXPORT_SYMBOL_GPL() > > That's easy enough, not sure I understand though why > of_dma_deconfigure() is not exported then. The second question mark > is about the dma-ranges equivalent in ACPI world; the _DMA method > seems to be the exact equivalent but to the best of my knowledge > it is ignored by the kernel, to really have an of_dma_configure() > equivalent that's really necessary, unless we want to resort to > arch specific methods (is that what x86 is currently doing ?) to > retrieve/build the dma masks. Please see the follow-up emails after my proposed patch: if we add a pointer to the device that firmware knows about in the USB core layer, there is no longer a problem to be solved and the DMA operations will do the right thing. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Wed, 14 Sep 2016 23:50:20 +0200 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <20160914163136.GA26842@red-moon> References: <874m5skmv9.fsf@linux.intel.com> <20160914163136.GA26842@red-moon> Message-ID: <5948102.1fQRRodOXz@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday, September 14, 2016 5:31:36 PM CEST Lorenzo Pieralisi wrote: > On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote: > > > > Hi, > > > > Robin Murphy writes: > > > On 07/09/16 10:55, Peter Chen wrote: > > > [...] > > >>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(), > > >>> I think we should replace > > >>> > > >>> pdev->dev.dma_mask = dev->dma_mask; > > >>> pdev->dev.dma_parms = dev->dma_parms; > > >>> dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask); > > >>> > > >>> with of_dma_configure(), which has the chance to configure more than > > >>> just those three, as the dma API might look into different aspects: > > >>> > > >>> - iommu specific configuration > > >>> - cache coherency information > > >>> - bus type > > >>> - dma offset > > >>> - dma_map_ops pointer > > >>> > > >>> We try to handle everything in of_dma_configure() at configuration > > >>> time, and that would be the place to add anything else that we might > > >>> need in the future. > > >>> > > >> > > >> Yes, I agree with you, but just like Felipe mentioned, we also need to > > >> consider PCI device, can we do something like gpiod_get_index does? Are > > >> there any similar APIs like of_dma_configure for ACPI? > > > > > > Not yet, but Lorenzo has one in progress[1], primarily for the sake of > > > abstracting away the IOMMU configuration. > > > > > > Robin. > > > > > > [1]:http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1209911.html > > > > not exported for drivers to use. If Lorenzo is trying to making a > > matching API for ACPI systems, then it needs to follow what > > of_dma_configure() is doing, and add an EXPORT_SYMBOL_GPL() > > That's easy enough, not sure I understand though why > of_dma_deconfigure() is not exported then. The second question mark > is about the dma-ranges equivalent in ACPI world; the _DMA method > seems to be the exact equivalent but to the best of my knowledge > it is ignored by the kernel, to really have an of_dma_configure() > equivalent that's really necessary, unless we want to resort to > arch specific methods (is that what x86 is currently doing ?) to > retrieve/build the dma masks. Please see the follow-up emails after my proposed patch: if we add a pointer to the device that firmware knows about in the USB core layer, there is no longer a problem to be solved and the DMA operations will do the right thing. Arnd