linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: David Laight <David.Laight@ACULAB.COM>, Mason <slash.tmp@free.fr>
Cc: Bjorn Helgaas <helgaas@kernel.org>, Rob Herring <robh@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Thibaud Cornic <thibaud_cornic@sigmadesigns.com>,
	linux-usb <linux-usb@vger.kernel.org>,
	Phuong Nguyen <phuong_nguyen@sigmadesigns.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Neophyte questions about PCIe
Date: Fri, 10 Mar 2017 16:00:32 +0000	[thread overview]
Message-ID: <504fdb97-f058-e1fb-0fe2-7f01c46db513@arm.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DCFE7C9B9@AcuExch.aculab.com>

On 10/03/17 15:35, David Laight wrote:
> From: Robin Murphy 
>> Sent: 10 March 2017 15:23
> ...
>>>> So you have 128MB (max) of system memory that has cpu physical
>>>> addresses 0x80000000 upwards.
>>>> I'd expect it all to be accessible from any PCIe card at some PCIe
>>>> address, it might be at address 0, 0x80000000 or any other offset.
>>>>
>>>> I don't know which DT entry controls that offset.
>>>
>>> This is a crucial point, I think.
>>
>> The appropriate DT property would be "dma-ranges", i.e.
>>
>> pci@... {
>> 	...
>> 	dma-ranges = <(PCI bus address) (CPU phys address) (size)>;
>> }
> 
> Isn't that just saying which physical addresses the cpu can assign
> for buffers for those devices?
> There is also an offset between the 'cpu physical address' and the
> 'dma address'.

That offset is inherent in what "dma-ranges" describes. Say (for ease of
calculation) that BAR0 has been put at a mem space address of 0x20000000
and maps the first 1GB of physical DRAM. That would give us:

	dma-ranges = <0x20000000 0x80000000 0x40000000>;

Then a "virt = dma_alloc_coherent(..., &handle, ...)", borrowing the
numbers from earlier in the thread, would automatically end up with:

	virt == 0xd0855000;
	handle == 0x2e07e000;

(with the physical address of 0x8e07e000 in between being irrelevant to
the consuming driver)

It is true that the device's DMA mask assignment is also part and parcel
of this, whereby we will limit what physical addresses the kernel
considers valid for DMA involving devices behind this range to the lower
3GB (i.e. 0x80000000 + 0x40000000 - 1). With a bit of luck,
CONFIG_DMABOUNCE should do the rest of the job of working around that
where necessary.

Robin.

> This might be implicit in the 'BAR0' base address register.
>  
>> The fun part is that that will only actually match the hardware once the
>> magic BAR has actually been programmed with (bus address), so you end up
>> with this part of your DT being more of a prophecy than a property :)
> 
> The BAR0 values could easily be programmed into the cpld/fpga - so
> not need writing by the cpu at all.
> 
> 	David
> 

  reply	other threads:[~2017-03-10 16:00 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-07 22:45 Neophyte questions about PCIe Mason
2017-03-08 13:39 ` Mason
2017-03-08 13:54 ` David Laight
2017-03-08 14:17   ` Mason
2017-03-08 14:38     ` David Laight
2017-03-09 22:01   ` Jeremy Linton
2017-03-08 15:17 ` Bjorn Helgaas
2017-03-09 23:43   ` Mason
2017-03-10 13:15     ` Robin Murphy
2017-03-10 14:06       ` David Laight
2017-03-10 15:05         ` Mason
2017-03-10 15:14           ` David Laight
2017-03-10 15:33             ` Mason
2017-03-10 15:23           ` Robin Murphy
2017-03-10 15:35             ` David Laight
2017-03-10 16:00               ` Robin Murphy [this message]
2017-03-13 10:59                 ` Mason
2017-03-13 11:56                   ` Robin Murphy
2017-03-10 18:49           ` Bjorn Helgaas
2017-03-10 14:53       ` Mason
2017-03-10 16:45     ` Mason
2017-03-10 17:49       ` Mason
2017-03-11 10:57         ` Mason
2017-03-13 21:40           ` Bjorn Helgaas
2017-03-13 21:57             ` Mason
2017-03-13 22:46               ` Bjorn Helgaas
2017-03-14 10:23               ` David Laight
2017-03-14 12:05                 ` Mason
2017-03-14 12:24                   ` David Laight
2017-03-13 14:25         ` Mason
2017-03-14 14:00         ` Mason
2017-03-14 15:54           ` Mason
2017-03-14 21:46             ` Bjorn Helgaas

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=504fdb97-f058-e1fb-0fe2-7f01c46db513@arm.com \
    --to=robin.murphy@arm.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=helgaas@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=phuong_nguyen@sigmadesigns.com \
    --cc=robh@kernel.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=slash.tmp@free.fr \
    --cc=thibaud_cornic@sigmadesigns.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).