From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935822AbdACUaw (ORCPT ); Tue, 3 Jan 2017 15:30:52 -0500 Received: from mail-lf0-f44.google.com ([209.85.215.44]:35438 "EHLO mail-lf0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933606AbdACUap (ORCPT ); Tue, 3 Jan 2017 15:30:45 -0500 Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask To: Grygorii Strashko , Will Deacon References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <20170103184444.GP6986@arm.com> <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com> Cc: Arnd Bergmann , 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, linux-arm-kernel@lists.infradead.org From: Nikita Yushchenko X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 3 Jan 2017 23:23:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c >>>> index 290a84f..49645277 100644 >>>> --- a/arch/arm64/mm/dma-mapping.c >>>> +++ b/arch/arm64/mm/dma-mapping.c >>>> @@ -28,6 +28,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> #include >>>> >>>> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt, >>>> >>>> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask) >>>> { >>>> +#ifdef CONFIG_PCI >>>> + if (dev_is_pci(hwdev)) { >>>> + struct pci_dev *pdev = to_pci_dev(hwdev); >>>> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus); >>>> + >>>> + if (br->dev.dma_mask && (*br->dev.dma_mask) && >>>> + (mask & (*br->dev.dma_mask)) != mask) >>>> + return 0; >>>> + } >>>> +#endif >>> >>> Hmm, but this makes it look like the problem is both arm64 and swiotlb >>> specific, when in reality it's not. Perhaps another hack you could try >>> would be to register a PCI bus notifier in the host bridge looking for >>> BUS_NOTIFY_BIND_DRIVER, then you could proxy the DMA ops for each child >>> device before the driver has probed, but adding a dma_set_mask callback >>> to limit the mask to what you need? >> >> This is what Renesas BSP tries to do and it does not work. >> >> BUS_NOTIFY_BIND_DRIVER arrives after driver's probe routine exits, but >> i/o can be started before that. > > Hm. This is strange statement: > really_probe > |->driver_sysfs_add > |-> blocking_notifier_call_chain(&dev->bus->p->bus_notifier, > BUS_NOTIFY_BIND_DRIVER, dev); > ... > |- ret = drv->probe(dev); > ... > |- driver_bound(dev); > |- blocking_notifier_call_chain(&dev->bus->p->bus_notifier, > BUS_NOTIFY_BOUND_DRIVER, dev); > > Am I missing smth? I misinterpreted your message, sorry. BSP attaches to BUS_NOTIFY_BOUND_DRIVER, not to BUS_NOTIFY_BIND_DRIVER, and simply overwrites device's dma_mask there. You are suggesting something completely different. I'll check if your approach is practical. Currently powerpc architecture has one more approach implemented, they use pci_controller structure provided by host bridge driver, and that has a set_dma_mask() hook. Maybe extending this beyond powerpc could be a good idea. However, that will require changing quite a few host bridge drivers, without any gain for most of those... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask To: Grygorii Strashko , Will Deacon References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <20170103184444.GP6986@arm.com> <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com> From: Nikita Yushchenko Message-ID: Date: Tue, 3 Jan 2017 23:23:06 +0300 MIME-Version: 1.0 In-Reply-To: <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Arnd Bergmann , 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, 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: >>>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c >>>> index 290a84f..49645277 100644 >>>> --- a/arch/arm64/mm/dma-mapping.c >>>> +++ b/arch/arm64/mm/dma-mapping.c >>>> @@ -28,6 +28,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> #include >>>> >>>> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt, >>>> >>>> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask) >>>> { >>>> +#ifdef CONFIG_PCI >>>> + if (dev_is_pci(hwdev)) { >>>> + struct pci_dev *pdev = to_pci_dev(hwdev); >>>> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus); >>>> + >>>> + if (br->dev.dma_mask && (*br->dev.dma_mask) && >>>> + (mask & (*br->dev.dma_mask)) != mask) >>>> + return 0; >>>> + } >>>> +#endif >>> >>> Hmm, but this makes it look like the problem is both arm64 and swiotlb >>> specific, when in reality it's not. Perhaps another hack you could try >>> would be to register a PCI bus notifier in the host bridge looking for >>> BUS_NOTIFY_BIND_DRIVER, then you could proxy the DMA ops for each child >>> device before the driver has probed, but adding a dma_set_mask callback >>> to limit the mask to what you need? >> >> This is what Renesas BSP tries to do and it does not work. >> >> BUS_NOTIFY_BIND_DRIVER arrives after driver's probe routine exits, but >> i/o can be started before that. > > Hm. This is strange statement: > really_probe > |->driver_sysfs_add > |-> blocking_notifier_call_chain(&dev->bus->p->bus_notifier, > BUS_NOTIFY_BIND_DRIVER, dev); > ... > |- ret = drv->probe(dev); > ... > |- driver_bound(dev); > |- blocking_notifier_call_chain(&dev->bus->p->bus_notifier, > BUS_NOTIFY_BOUND_DRIVER, dev); > > Am I missing smth? I misinterpreted your message, sorry. BSP attaches to BUS_NOTIFY_BOUND_DRIVER, not to BUS_NOTIFY_BIND_DRIVER, and simply overwrites device's dma_mask there. You are suggesting something completely different. I'll check if your approach is practical. Currently powerpc architecture has one more approach implemented, they use pci_controller structure provided by host bridge driver, and that has a set_dma_mask() hook. Maybe extending this beyond powerpc could be a good idea. However, that will require changing quite a few host bridge drivers, without any gain for most of those... _______________________________________________ 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: nikita.yoush@cogentembedded.com (Nikita Yushchenko) Date: Tue, 3 Jan 2017 23:23:06 +0300 Subject: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask In-Reply-To: <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com> References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <20170103184444.GP6986@arm.com> <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org >>>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c >>>> index 290a84f..49645277 100644 >>>> --- a/arch/arm64/mm/dma-mapping.c >>>> +++ b/arch/arm64/mm/dma-mapping.c >>>> @@ -28,6 +28,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> #include >>>> >>>> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt, >>>> >>>> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask) >>>> { >>>> +#ifdef CONFIG_PCI >>>> + if (dev_is_pci(hwdev)) { >>>> + struct pci_dev *pdev = to_pci_dev(hwdev); >>>> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus); >>>> + >>>> + if (br->dev.dma_mask && (*br->dev.dma_mask) && >>>> + (mask & (*br->dev.dma_mask)) != mask) >>>> + return 0; >>>> + } >>>> +#endif >>> >>> Hmm, but this makes it look like the problem is both arm64 and swiotlb >>> specific, when in reality it's not. Perhaps another hack you could try >>> would be to register a PCI bus notifier in the host bridge looking for >>> BUS_NOTIFY_BIND_DRIVER, then you could proxy the DMA ops for each child >>> device before the driver has probed, but adding a dma_set_mask callback >>> to limit the mask to what you need? >> >> This is what Renesas BSP tries to do and it does not work. >> >> BUS_NOTIFY_BIND_DRIVER arrives after driver's probe routine exits, but >> i/o can be started before that. > > Hm. This is strange statement: > really_probe > |->driver_sysfs_add > |-> blocking_notifier_call_chain(&dev->bus->p->bus_notifier, > BUS_NOTIFY_BIND_DRIVER, dev); > ... > |- ret = drv->probe(dev); > ... > |- driver_bound(dev); > |- blocking_notifier_call_chain(&dev->bus->p->bus_notifier, > BUS_NOTIFY_BOUND_DRIVER, dev); > > Am I missing smth? I misinterpreted your message, sorry. BSP attaches to BUS_NOTIFY_BOUND_DRIVER, not to BUS_NOTIFY_BIND_DRIVER, and simply overwrites device's dma_mask there. You are suggesting something completely different. I'll check if your approach is practical. Currently powerpc architecture has one more approach implemented, they use pci_controller structure provided by host bridge driver, and that has a set_dma_mask() hook. Maybe extending this beyond powerpc could be a good idea. However, that will require changing quite a few host bridge drivers, without any gain for most of those...