Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-02-16 Thread Arnd Bergmann
On Thursday, December 29, 2016 11:45:03 PM CET Nikita Yushchenko wrote: > > 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

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-10 Thread Arnd Bergmann
On Tuesday, January 10, 2017 3:44:53 PM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote: > > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > > 32-bit architectures without swiotlb (arc, arm, some mips32), and > > there are several

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-10 Thread Christoph Hellwig
On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote: > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > 32-bit architectures without swiotlb (arc, arm, some mips32), and > there are several 64-bit architectures that do not have swiotlb > (alpha, parisc, s390, sparc). I

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-10 Thread Arnd Bergmann
On Monday, January 9, 2017 9:57:46 PM CET Christoph Hellwig wrote: > > - architecture should stop breaking 64-bit DMA when driver attempts to > > set 64-bit dma mask, > > > > - NVMe should issue proper blk_queue_bounce_limit() call based on what > > is actually set mask, > > Or even better

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-09 Thread Christoph Hellwig
On Mon, Jan 09, 2017 at 11:34:55PM +0300, Nikita Yushchenko wrote: > I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC > but in block layer, in particular it should be controlled by > blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it > is something

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-09 Thread Nikita Yushchenko
[CCing NVMe maintainers since we are discussion issues in that driver] >> With my patch applied and thus 32bit dma_mask set for NVMe device, I do >> see high addresses passed to dma_map_*() routines and handled by >> swiotlb. Thus your statement that behavior "succeed 64bit dma_set_mask() >>

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-09 Thread Arnd Bergmann
On Friday, January 6, 2017 4:47:59 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. > > I've

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-06 Thread Nikita Yushchenko
>>> 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. I've re-checked rcar-pcie hardware documentation. It indeed mentions that AXI bus

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-06 Thread Arnd Bergmann
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

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-04 Thread Nikita Yushchenko
For OF platforms, this is called via of_dma_configure(), that checks dma-ranges of node that is *parent* for host bridge. Host bridge currently does not control this at all. >>> >>> We need to think about this a bit. Is it actually the PCI host >>> bridge that limits the ranges

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-04 Thread Arnd Bergmann
On Wednesday, January 4, 2017 5:30:19 PM CET Nikita Yushchenko wrote: > >> For OF platforms, this is called via of_dma_configure(), that checks > >> dma-ranges of node that is *parent* for host bridge. Host bridge > >> currently does not control this at all. > > > > We need to think about this a

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-04 Thread Nikita Yushchenko
>> For OF platforms, this is called via of_dma_configure(), that checks >> dma-ranges of node that is *parent* for host bridge. Host bridge >> currently does not control this at all. > > We need to think about this a bit. Is it actually the PCI host > bridge that limits the ranges here, or the

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-04 Thread Arnd Bergmann
On Wednesday, January 4, 2017 9:24:09 AM CET Nikita Yushchenko wrote: > > commit 9a57d58d116800a535510053136c6dd7a9c26e25 > > Author: Arnd Bergmann > > Date: Tue Nov 17 14:06:55 2015 +0100 > > > > [EXPERIMENTAL] ARM64: check implement dma_set_mask > > > > Needs work

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-03 Thread Nikita Yushchenko
> commit 9a57d58d116800a535510053136c6dd7a9c26e25 > Author: Arnd Bergmann > Date: Tue Nov 17 14:06:55 2015 +0100 > > [EXPERIMENTAL] ARM64: check implement dma_set_mask > > Needs work for coherent mask > > Signed-off-by: Arnd Bergmann

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-03 Thread Arnd Bergmann
On Tuesday, January 3, 2017 6:44:44 PM CET Will Deacon wrote: > > @@ -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

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-03 Thread Grygorii Strashko
On 01/03/2017 01:01 PM, Nikita Yushchenko wrote: >>> It is possible that PCI device supports 64-bit DMA addressing, and thus >>> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host >>> bridge has limitations on inbound transactions addressing. Example of >>> such setup is

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-03 Thread Nikita Yushchenko
>> It is possible that PCI device supports 64-bit DMA addressing, and thus >> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host >> bridge has limitations on inbound transactions addressing. Example of >> such setup is NVME SSD device connected to RCAR PCIe controller. >> >>

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2017-01-03 Thread Will Deacon
On Thu, Dec 29, 2016 at 11:45:03PM +0300, Nikita Yushchenko wrote: > It is possible that PCI device supports 64-bit DMA addressing, and thus > it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host > bridge has limitations on inbound transactions addressing. Example of > such

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2016-12-30 Thread Sergei Shtylyov
On 12/30/2016 12:46 PM, Sergei Shtylyov wrote: It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host Its. bridge has limitations on inbound transactions addressing. Example of such setup is NVME

[PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

2016-12-29 Thread Nikita Yushchenko
It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge has limitations on inbound transactions addressing. Example of such setup is NVME SSD device connected to RCAR PCIe controller. Previously there