All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>, Jens Axboe <axboe@kernel.dk>,
	Joerg Roedel <joro@8bytes.org>, Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Paul Burton <paulburton@kernel.org>,
	James Hogan <jhogan@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-ide@vger.kernel.org, iommu@lists.linux-foundation.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
Date: Thu, 21 Nov 2019 16:24:57 +0100	[thread overview]
Message-ID: <20191121152457.GA525@lst.de> (raw)
In-Reply-To: <20191121092646.8449-1-nsaenzjulienne@suse.de>

On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a limit. This quirk is already used by some architectures although
> still rare.
> 
> With the introduction of the Raspberry Pi 4 we've found a new contender
> for the use of bus DMA limits, as its PCIe bus can only address the
> lower 3GB of memory (of a total of 4GB). This is impossible to represent
> with a mask. To make things worse the device-tree code rounds non power
> of two bus DMA limits to the next power of two, which is unacceptable in
> this case.
> 
> In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> over the tree and treat it as such. Note that dev->bus_dma_limit should
> contain the higher accesible DMA address.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

I've tentatively added this patch to the dma-mapping tree based on
Robins principal approval of the last version.  That way tomorrows
linux-next run should still pick it up.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-ide@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Frank Rowand <frowand.list@gmail.com>,
	Christoph Hellwig <hch@lst.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Paul Burton <paulburton@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	x86@kernel.org, linux-acpi@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>, James Hogan <jhogan@kernel.org>,
	Len Brown <lenb@kernel.org>,
	devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Jens Axboe <axboe@kernel.dk>,
	linuxppc-dev@lists.ozlabs.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	iommu@lists.linux-foundation.org,
	Sudeep Holla <sudeep.holla@arm.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
Date: Thu, 21 Nov 2019 16:24:57 +0100	[thread overview]
Message-ID: <20191121152457.GA525@lst.de> (raw)
In-Reply-To: <20191121092646.8449-1-nsaenzjulienne@suse.de>

On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a limit. This quirk is already used by some architectures although
> still rare.
> 
> With the introduction of the Raspberry Pi 4 we've found a new contender
> for the use of bus DMA limits, as its PCIe bus can only address the
> lower 3GB of memory (of a total of 4GB). This is impossible to represent
> with a mask. To make things worse the device-tree code rounds non power
> of two bus DMA limits to the next power of two, which is unacceptable in
> this case.
> 
> In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> over the tree and treat it as such. Note that dev->bus_dma_limit should
> contain the higher accesible DMA address.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

I've tentatively added this patch to the dma-mapping tree based on
Robins principal approval of the last version.  That way tomorrows
linux-next run should still pick it up.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-ide@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Frank Rowand <frowand.list@gmail.com>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Paul Burton <paulburton@kernel.org>,
	Joerg Roedel <joro@8bytes.org>,
	x86@kernel.org, linux-acpi@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>, James Hogan <jhogan@kernel.org>,
	Len Brown <lenb@kernel.org>,
	devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Jens Axboe <axboe@kernel.dk>,
	linuxppc-dev@lists.ozlabs.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	iommu@lists.linux-foundation.org,
	Sudeep Holla <sudeep.holla@arm.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
Date: Thu, 21 Nov 2019 16:24:57 +0100	[thread overview]
Message-ID: <20191121152457.GA525@lst.de> (raw)
In-Reply-To: <20191121092646.8449-1-nsaenzjulienne@suse.de>

On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a limit. This quirk is already used by some architectures although
> still rare.
> 
> With the introduction of the Raspberry Pi 4 we've found a new contender
> for the use of bus DMA limits, as its PCIe bus can only address the
> lower 3GB of memory (of a total of 4GB). This is impossible to represent
> with a mask. To make things worse the device-tree code rounds non power
> of two bus DMA limits to the next power of two, which is unacceptable in
> this case.
> 
> In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> over the tree and treat it as such. Note that dev->bus_dma_limit should
> contain the higher accesible DMA address.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

I've tentatively added this patch to the dma-mapping tree based on
Robins principal approval of the last version.  That way tomorrows
linux-next run should still pick it up.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-ide@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Frank Rowand <frowand.list@gmail.com>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Paul Burton <paulburton@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Joerg Roedel <joro@8bytes.org>,
	x86@kernel.org, linux-acpi@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>, James Hogan <jhogan@kernel.org>,
	Len Brown <lenb@kernel.org>,
	devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Jens Axboe <axboe@kernel.dk>,
	linuxppc-dev@lists.ozlabs.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	iommu@lists.linux-foundation.org,
	Sudeep Holla <sudeep.holla@arm.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
Date: Thu, 21 Nov 2019 16:24:57 +0100	[thread overview]
Message-ID: <20191121152457.GA525@lst.de> (raw)
In-Reply-To: <20191121092646.8449-1-nsaenzjulienne@suse.de>

On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a limit. This quirk is already used by some architectures although
> still rare.
> 
> With the introduction of the Raspberry Pi 4 we've found a new contender
> for the use of bus DMA limits, as its PCIe bus can only address the
> lower 3GB of memory (of a total of 4GB). This is impossible to represent
> with a mask. To make things worse the device-tree code rounds non power
> of two bus DMA limits to the next power of two, which is unacceptable in
> this case.
> 
> In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> over the tree and treat it as such. Note that dev->bus_dma_limit should
> contain the higher accesible DMA address.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

I've tentatively added this patch to the dma-mapping tree based on
Robins principal approval of the last version.  That way tomorrows
linux-next run should still pick it up.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-11-21 15:25 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-21  9:26 [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit Nicolas Saenz Julienne
2019-11-21  9:26 ` Nicolas Saenz Julienne
2019-11-21  9:26 ` Nicolas Saenz Julienne
2019-11-21  9:26 ` Nicolas Saenz Julienne
2019-11-21 15:24 ` Christoph Hellwig [this message]
2019-11-21 15:24   ` Christoph Hellwig
2019-11-21 15:24   ` Christoph Hellwig
2019-11-21 15:24   ` Christoph Hellwig
2019-11-21 15:26   ` Nicolas Saenz Julienne
2019-11-21 15:26     ` Nicolas Saenz Julienne
2019-11-21 15:26     ` Nicolas Saenz Julienne
2019-11-21 15:26     ` Nicolas Saenz Julienne
2019-11-21 15:26   ` Christoph Hellwig
2019-11-21 15:26     ` Christoph Hellwig
2019-11-21 15:26     ` Christoph Hellwig
2019-11-21 15:26     ` Christoph Hellwig
2019-11-21 15:55     ` Robin Murphy
2019-11-21 15:55       ` Robin Murphy
2019-11-21 15:55       ` Robin Murphy
2019-11-21 15:55       ` Robin Murphy
2019-11-21 16:02       ` Christoph Hellwig
2019-11-21 16:02         ` Christoph Hellwig
2019-11-21 16:02         ` Christoph Hellwig
2019-11-21 16:02         ` Christoph Hellwig
2019-11-21 16:53         ` Will Deacon
2019-11-21 16:53           ` Will Deacon
2019-11-21 16:53           ` Will Deacon
2019-11-21 16:53           ` Will Deacon
2019-11-21 17:16           ` Christoph Hellwig
2019-11-21 17:16             ` Christoph Hellwig
2019-11-21 17:16             ` Christoph Hellwig
2019-11-21 17:16             ` Christoph Hellwig
2019-11-21 17:07 ` Robin Murphy
2019-11-21 17:07   ` Robin Murphy
2019-11-21 17:07   ` Robin Murphy
2019-11-21 17:07   ` Robin Murphy
2019-11-21 17:17   ` Christoph Hellwig
2019-11-21 17:17     ` Christoph Hellwig
2019-11-21 17:17     ` Christoph Hellwig
2019-11-21 17:17     ` Christoph Hellwig
2019-11-23 16:51 ` Nathan Chancellor
2019-11-23 16:51   ` Nathan Chancellor
2019-11-23 16:51   ` Nathan Chancellor
2019-11-23 16:51   ` Nathan Chancellor
2019-11-25  7:44   ` Christoph Hellwig
2019-11-25  7:44     ` Christoph Hellwig
2019-11-25  7:44     ` Christoph Hellwig
2019-11-25  7:44     ` Christoph Hellwig
2019-11-25 16:33     ` Robin Murphy
2019-11-25 16:33       ` Robin Murphy
2019-11-25 16:33       ` Robin Murphy
2019-11-25 16:33       ` Robin Murphy
2019-11-26 18:51       ` Nicolas Saenz Julienne
2019-11-26 18:51         ` Nicolas Saenz Julienne
2019-11-26 18:51         ` Nicolas Saenz Julienne
2019-11-26 18:51         ` Nicolas Saenz Julienne
2019-11-26 21:45         ` Robin Murphy
2019-11-26 21:45           ` Robin Murphy
2019-11-26 21:45           ` Robin Murphy
2019-11-26 21:45           ` Robin Murphy

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=20191121152457.GA525@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=guohanjun@huawei.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jhogan@kernel.org \
    --cc=joro@8bytes.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=luto@kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=nsaenzjulienne@suse.de \
    --cc=paulburton@kernel.org \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=ralf@linux-mips.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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.