All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Will Deacon <will.deacon@arm.com>,
	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
Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
Date: Wed, 4 Jan 2017 17:30:19 +0300	[thread overview]
Message-ID: <412396ac-4535-08a3-e4c7-dd8d0078a518@cogentembedded.com> (raw)
In-Reply-To: <2104402.puPT8SttTe@wuerfel>

>> 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 bus that it is connected
> to. In the latter case, the caller needs to be adapted to handle
> both.

In r-car case, I'm not sure what is the source of limitation at physical
level.

pcie-rcar driver configures ranges for PCIe inbound transactions based
on dma-ranges property in it's device tree node. In the current device
tree for this platform, that only contains one range and it is in lower
memory.

NVMe driver tries i/o to kmalloc()ed area. That returns 0x5xxxxxxxx
addresses here. As a quick experiment, I tried to add second range to
pcie-rcar's dma-ranges to cover 0x5xxxxxxxx area - but that did not make
DMA to high addresses working.

My current understanding is that host bridge hardware module can't
handle inbound transactions to PCI addresses above 4G - and this
limitations comes from host bridge itself.

I've read somewhere in the lists that pcie-rcar hardware is "32-bit" -
but I don't remember where, and don't know lowlevel details. Maybe
somebody from linux-renesas can elaborate?


>> In current device trees no dma-ranges is defined for nodes that are
>> parents to pci host bridges. This will make of_dma_configure() to fall
>> back to 32-bit size for all devices on all current platforms.  Thus
>> applying this patch will immediately break 64-bit dma masks on all
>> hardware that supports it.
> 
> No, it won't break it, it will just fall back to swiotlb for all the
> ones that are lacking the dma-ranges property. I think this is correct
> behavior.

I'd say - for all ones that have parents without dma-ranges property.

As of 4.10-rc2, I see only two definitions of wide parent dma-ranges
under arch/arm64/boot/dts/ - in amd/amd-seattle-soc.dtsi and
apm/apm-storm.dtsi

Are these the only arm64 platforms that can to DMA to high addresses?
I'm not arm64 expert but I'd be surprised if that's the case.


>> Also related: dma-ranges property used by several pci host bridges is
>> *not* compatible with "legacy" dma-ranges parsed by of_get_dma_range() -
>> former uses additional flags word at beginning.
> 
> Can you elaborate? Do we have PCI host bridges that use wrongly formatted
> dma-ranges properties?

of_dma_get_range() expects <dma_addr cpu_addr size> format.

pcie-rcar.c, pci-rcar-gen2.c, pci-xgene.c and pcie-iproc.c from
drivers/pci/host/ all parse dma-ranges using of_pci_range_parser that
uses <flags pci-addr cpu-addr size> format - i.e. something different
from what of_dma_get_range() uses.


Nikita

WARNING: multiple messages have this Message-ID (diff)
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@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: Wed, 4 Jan 2017 17:30:19 +0300	[thread overview]
Message-ID: <412396ac-4535-08a3-e4c7-dd8d0078a518@cogentembedded.com> (raw)
In-Reply-To: <2104402.puPT8SttTe@wuerfel>

>> 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 bus that it is connected
> to. In the latter case, the caller needs to be adapted to handle
> both.

In r-car case, I'm not sure what is the source of limitation at physical
level.

pcie-rcar driver configures ranges for PCIe inbound transactions based
on dma-ranges property in it's device tree node. In the current device
tree for this platform, that only contains one range and it is in lower
memory.

NVMe driver tries i/o to kmalloc()ed area. That returns 0x5xxxxxxxx
addresses here. As a quick experiment, I tried to add second range to
pcie-rcar's dma-ranges to cover 0x5xxxxxxxx area - but that did not make
DMA to high addresses working.

My current understanding is that host bridge hardware module can't
handle inbound transactions to PCI addresses above 4G - and this
limitations comes from host bridge itself.

I've read somewhere in the lists that pcie-rcar hardware is "32-bit" -
but I don't remember where, and don't know lowlevel details. Maybe
somebody from linux-renesas can elaborate?


>> In current device trees no dma-ranges is defined for nodes that are
>> parents to pci host bridges. This will make of_dma_configure() to fall
>> back to 32-bit size for all devices on all current platforms.  Thus
>> applying this patch will immediately break 64-bit dma masks on all
>> hardware that supports it.
> 
> No, it won't break it, it will just fall back to swiotlb for all the
> ones that are lacking the dma-ranges property. I think this is correct
> behavior.

I'd say - for all ones that have parents without dma-ranges property.

As of 4.10-rc2, I see only two definitions of wide parent dma-ranges
under arch/arm64/boot/dts/ - in amd/amd-seattle-soc.dtsi and
apm/apm-storm.dtsi

Are these the only arm64 platforms that can to DMA to high addresses?
I'm not arm64 expert but I'd be surprised if that's the case.


>> Also related: dma-ranges property used by several pci host bridges is
>> *not* compatible with "legacy" dma-ranges parsed by of_get_dma_range() -
>> former uses additional flags word at beginning.
> 
> Can you elaborate? Do we have PCI host bridges that use wrongly formatted
> dma-ranges properties?

of_dma_get_range() expects <dma_addr cpu_addr size> format.

pcie-rcar.c, pci-rcar-gen2.c, pci-xgene.c and pcie-iproc.c from
drivers/pci/host/ all parse dma-ranges using of_pci_range_parser that
uses <flags pci-addr cpu-addr size> format - i.e. something different
from what of_dma_get_range() uses.


Nikita

_______________________________________________
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: Wed, 4 Jan 2017 17:30:19 +0300	[thread overview]
Message-ID: <412396ac-4535-08a3-e4c7-dd8d0078a518@cogentembedded.com> (raw)
In-Reply-To: <2104402.puPT8SttTe@wuerfel>

>> 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 bus that it is connected
> to. In the latter case, the caller needs to be adapted to handle
> both.

In r-car case, I'm not sure what is the source of limitation at physical
level.

pcie-rcar driver configures ranges for PCIe inbound transactions based
on dma-ranges property in it's device tree node. In the current device
tree for this platform, that only contains one range and it is in lower
memory.

NVMe driver tries i/o to kmalloc()ed area. That returns 0x5xxxxxxxx
addresses here. As a quick experiment, I tried to add second range to
pcie-rcar's dma-ranges to cover 0x5xxxxxxxx area - but that did not make
DMA to high addresses working.

My current understanding is that host bridge hardware module can't
handle inbound transactions to PCI addresses above 4G - and this
limitations comes from host bridge itself.

I've read somewhere in the lists that pcie-rcar hardware is "32-bit" -
but I don't remember where, and don't know lowlevel details. Maybe
somebody from linux-renesas can elaborate?


>> In current device trees no dma-ranges is defined for nodes that are
>> parents to pci host bridges. This will make of_dma_configure() to fall
>> back to 32-bit size for all devices on all current platforms.  Thus
>> applying this patch will immediately break 64-bit dma masks on all
>> hardware that supports it.
> 
> No, it won't break it, it will just fall back to swiotlb for all the
> ones that are lacking the dma-ranges property. I think this is correct
> behavior.

I'd say - for all ones that have parents without dma-ranges property.

As of 4.10-rc2, I see only two definitions of wide parent dma-ranges
under arch/arm64/boot/dts/ - in amd/amd-seattle-soc.dtsi and
apm/apm-storm.dtsi

Are these the only arm64 platforms that can to DMA to high addresses?
I'm not arm64 expert but I'd be surprised if that's the case.


>> Also related: dma-ranges property used by several pci host bridges is
>> *not* compatible with "legacy" dma-ranges parsed by of_get_dma_range() -
>> former uses additional flags word at beginning.
> 
> Can you elaborate? Do we have PCI host bridges that use wrongly formatted
> dma-ranges properties?

of_dma_get_range() expects <dma_addr cpu_addr size> format.

pcie-rcar.c, pci-rcar-gen2.c, pci-xgene.c and pcie-iproc.c from
drivers/pci/host/ all parse dma-ranges using of_pci_range_parser that
uses <flags pci-addr cpu-addr size> format - i.e. something different
from what of_dma_get_range() uses.


Nikita

  reply	other threads:[~2017-01-04 14:31 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
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 [this message]
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=412396ac-4535-08a3-e4c7-dd8d0078a518@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=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.