All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
To: Grygorii Strashko <grygorii.strashko@ti.com>,
	Will Deacon <will.deacon@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Simon Horman <horms@verge.net.au>,
	linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	artemi.ivanov@cogentembedded.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
Date: Tue, 3 Jan 2017 23:23:06 +0300	[thread overview]
Message-ID: <bd587495-0c88-005f-c1b6-9ce05e20fcbc@cogentembedded.com> (raw)
In-Reply-To: <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com>

>>>> 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 <linux/dma-contiguous.h>
>>>>  #include <linux/vmalloc.h>
>>>>  #include <linux/swiotlb.h>
>>>> +#include <linux/pci.h>
>>>>  
>>>>  #include <asm/cacheflush.h>
>>>>  
>>>> @@ -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...

WARNING: multiple messages have this Message-ID (diff)
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
To: Grygorii Strashko <grygorii.strashko@ti.com>,
	Will Deacon <will.deacon@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Simon Horman <horms@verge.net.au>,
	linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	artemi.ivanov@cogentembedded.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
Date: Tue, 3 Jan 2017 23:23:06 +0300	[thread overview]
Message-ID: <bd587495-0c88-005f-c1b6-9ce05e20fcbc@cogentembedded.com> (raw)
In-Reply-To: <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com>

>>>> 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 <linux/dma-contiguous.h>
>>>>  #include <linux/vmalloc.h>
>>>>  #include <linux/swiotlb.h>
>>>> +#include <linux/pci.h>
>>>>  
>>>>  #include <asm/cacheflush.h>
>>>>  
>>>> @@ -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

WARNING: multiple messages have this Message-ID (diff)
From: nikita.yoush@cogentembedded.com (Nikita Yushchenko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
Date: Tue, 3 Jan 2017 23:23:06 +0300	[thread overview]
Message-ID: <bd587495-0c88-005f-c1b6-9ce05e20fcbc@cogentembedded.com> (raw)
In-Reply-To: <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com>

>>>> 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 <linux/dma-contiguous.h>
>>>>  #include <linux/vmalloc.h>
>>>>  #include <linux/swiotlb.h>
>>>> +#include <linux/pci.h>
>>>>  
>>>>  #include <asm/cacheflush.h>
>>>>  
>>>> @@ -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...

  reply	other threads:[~2017-01-03 20:30 UTC|newest]

Thread overview: 115+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-29 20:45 [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Nikita Yushchenko
2016-12-29 20:45 ` Nikita Yushchenko
2016-12-29 20:45 ` [PATCH 2/2] rcar-pcie: set host bridge's " Nikita Yushchenko
2016-12-29 20:45   ` Nikita Yushchenko
2016-12-29 21:18 ` [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit " Arnd Bergmann
2017-02-16 16:12   ` Arnd Bergmann
2016-12-29 21:18   ` Arnd Bergmann
2016-12-30  9:46 ` Sergei Shtylyov
2016-12-30  9:46   ` Sergei Shtylyov
2016-12-30 10:06   ` Sergei Shtylyov
2016-12-30 10:06     ` Sergei Shtylyov
2017-01-03 18:44 ` Will Deacon
2017-01-03 18:44   ` Will Deacon
2017-01-03 19:00   ` Nikita Yushchenko
2017-01-03 19:00     ` Nikita Yushchenko
2017-01-03 19:01   ` Nikita Yushchenko
2017-01-03 19:01     ` Nikita Yushchenko
2017-01-03 19:01     ` Nikita Yushchenko
2017-01-03 20:13     ` Grygorii Strashko
2017-01-03 20:13       ` Grygorii Strashko
2017-01-03 20:13       ` Grygorii Strashko
2017-01-03 20:23       ` Nikita Yushchenko [this message]
2017-01-03 20:23         ` Nikita Yushchenko
2017-01-03 20:23         ` Nikita Yushchenko
2017-01-03 23:13   ` Arnd Bergmann
2017-01-03 23:13     ` Arnd Bergmann
2017-01-03 23:13     ` Arnd Bergmann
2017-01-04  6:24     ` Nikita Yushchenko
2017-01-04  6:24       ` Nikita Yushchenko
2017-01-04  6:24       ` Nikita Yushchenko
2017-01-04 13:29       ` Arnd Bergmann
2017-01-04 13:29         ` Arnd Bergmann
2017-01-04 13:29         ` Arnd Bergmann
2017-01-04 14:30         ` Nikita Yushchenko
2017-01-04 14:30           ` Nikita Yushchenko
2017-01-04 14:30           ` Nikita Yushchenko
2017-01-04 14:46           ` Arnd Bergmann
2017-01-04 14:46             ` Arnd Bergmann
2017-01-04 15:29             ` Nikita Yushchenko
2017-01-04 15:29               ` Nikita Yushchenko
2017-01-04 15:29               ` Nikita Yushchenko
2017-01-06 11:10               ` Arnd Bergmann
2017-01-06 11:10                 ` Arnd Bergmann
2017-01-06 11:10                 ` Arnd Bergmann
2017-01-06 13:47                 ` Nikita Yushchenko
2017-01-06 13:47                   ` Nikita Yushchenko
2017-01-06 13:47                   ` Nikita Yushchenko
2017-01-06 14:38                   ` [PATCH] arm64: do not set dma masks that device connection can't handle Nikita Yushchenko
2017-01-06 14:38                     ` Nikita Yushchenko
2017-01-06 14:45                   ` Nikita Yushchenko
2017-01-06 14:45                     ` Nikita Yushchenko
2017-01-08  7:09                     ` Sergei Shtylyov
2017-01-08  7:09                       ` Sergei Shtylyov
2017-01-09  6:56                       ` Nikita Yushchenko
2017-01-09  6:56                         ` Nikita Yushchenko
2017-01-09 14:05                   ` [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Arnd Bergmann
2017-01-09 14:05                     ` Arnd Bergmann
2017-01-09 14:05                     ` Arnd Bergmann
2017-01-09 20:34                     ` Nikita Yushchenko
2017-01-09 20:34                       ` Nikita Yushchenko
2017-01-09 20:34                       ` Nikita Yushchenko
2017-01-09 20:34                       ` Nikita Yushchenko
2017-01-09 20:57                       ` Christoph Hellwig
2017-01-09 20:57                         ` Christoph Hellwig
2017-01-09 20:57                         ` Christoph Hellwig
2017-01-09 20:57                         ` Christoph Hellwig
2017-01-10  6:47                         ` NVMe vs DMA addressing limitations Nikita Yushchenko
2017-01-10  7:07                           ` Christoph Hellwig
2017-01-10  7:07                             ` Christoph Hellwig
2017-01-10  7:07                             ` Christoph Hellwig
2017-01-10  7:07                             ` Christoph Hellwig
2017-01-10  7:31                             ` Nikita Yushchenko
2017-01-10  7:31                               ` Nikita Yushchenko
2017-01-10  7:31                               ` Nikita Yushchenko
2017-01-10  7:31                               ` Nikita Yushchenko
2017-01-10 11:01                               ` Arnd Bergmann
2017-01-10 11:01                                 ` Arnd Bergmann
2017-01-10 11:01                                 ` Arnd Bergmann
2017-01-10 11:01                                 ` Arnd Bergmann
2017-01-10 14:48                                 ` Christoph Hellwig
2017-01-10 14:48                                   ` Christoph Hellwig
2017-01-10 14:48                                   ` Christoph Hellwig
2017-01-10 14:48                                   ` Christoph Hellwig
2017-01-10 15:02                                   ` Arnd Bergmann
2017-01-10 15:02                                     ` Arnd Bergmann
2017-01-10 15:02                                     ` Arnd Bergmann
2017-01-10 15:02                                     ` Arnd Bergmann
2017-01-12 10:09                                   ` Sagi Grimberg
2017-01-12 10:09                                     ` Sagi Grimberg
2017-01-12 10:09                                     ` Sagi Grimberg
2017-01-12 10:09                                     ` Sagi Grimberg
2017-01-12 11:56                                     ` Arnd Bergmann
2017-01-12 11:56                                       ` Arnd Bergmann
2017-01-12 11:56                                       ` Arnd Bergmann
2017-01-12 11:56                                       ` Arnd Bergmann
2017-01-12 13:07                                       ` Christoph Hellwig
2017-01-12 13:07                                         ` Christoph Hellwig
2017-01-12 13:07                                         ` Christoph Hellwig
2017-01-12 13:07                                         ` Christoph Hellwig
2017-01-10 10:54                             ` Arnd Bergmann
2017-01-10 10:54                               ` Arnd Bergmann
2017-01-10 10:54                               ` Arnd Bergmann
2017-01-10 10:54                               ` Arnd Bergmann
2017-01-10 10:47                         ` [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Arnd Bergmann
2017-01-10 10:47                           ` Arnd Bergmann
2017-01-10 10:47                           ` Arnd Bergmann
2017-01-10 10:47                           ` Arnd Bergmann
2017-01-10 14:44                           ` Christoph Hellwig
2017-01-10 14:44                             ` Christoph Hellwig
2017-01-10 14:44                             ` Christoph Hellwig
2017-01-10 14:44                             ` Christoph Hellwig
2017-01-10 15:00                             ` Arnd Bergmann
2017-01-10 15:00                               ` Arnd Bergmann
2017-01-10 15:00                               ` Arnd Bergmann
2017-01-10 15:00                               ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd587495-0c88-005f-c1b6-9ce05e20fcbc@cogentembedded.com \
    --to=nikita.yoush@cogentembedded.com \
    --cc=arnd@arndb.de \
    --cc=artemi.ivanov@cogentembedded.com \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=grygorii.strashko@ti.com \
    --cc=horms@verge.net.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.