linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Roger Quadros <rogerq@ti.com>, Rob Herring <robh+dt@kernel.org>
Cc: "Christoph Hellwig" <hch@lst.de>,
	"Péter Ujfalusi" <peter.ujfalusi@ti.com>,
	"Murali Karicheri" <m-karicheri2@ti.com>,
	"Nori, Sekhar" <nsekhar@ti.com>, "Anna, Suman" <s-anna@ti.com>,
	"Stefan Wahren" <stefan.wahren@i2se.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Nishanth Menon" <nm@ti.com>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	"Vignesh Raghavendra" <vigneshr@ti.com>
Subject: Re: dma_mask limited to 32-bits with OF platform device
Date: Wed, 19 Feb 2020 15:25:29 +0000	[thread overview]
Message-ID: <827fa19d-1990-16bc-33f5-fc82ac0d4a8a@arm.com> (raw)
In-Reply-To: <15d0ac5f-4919-5852-cd95-93c24d8bdbb9@ti.com>

On 19/02/2020 2:29 pm, Roger Quadros wrote:
> Rob,
> 
> On 18/02/2020 19:22, Rob Herring wrote:
>> On Tue, Feb 18, 2020 at 2:28 AM Roger Quadros <rogerq@ti.com> wrote:
>>>
>>> Chrishtoph,
>>>
>>> The branch works fine for SATA on DRA7 with CONFIG_LPAE once I
>>> have the below DT fix.
>>>
>>> Do you intend to send these fixes to -stable?
>>>
>>> ------------------------- arch/arm/boot/dts/dra7.dtsi 
>>> -------------------------
>>> index d78b684e7fca..853ecf3cfb37 100644
>>> @@ -645,6 +645,8 @@
>>>                  sata: sata@4a141100 {
>>>                          compatible = "snps,dwc-ahci";
>>>                          reg = <0x4a140000 0x1100>, <0x4a141100 0x7>;
>>> +                       #size-cells = <2>;
>>> +                       dma-ranges = <0x00000000 0x00000000 0x1 
>>> 0x00000000>;
>>
>> dma-ranges should be in the parent (bus) node, not the device node.
> 
> I didn't understand why.
> 
> There are many devices on the parent bus node and all devices might not 
> have the 32-bit DMA limit
> the SATA controller has.
> 
> SATA controller is the bus master and the ATA devices are children of 
> the SATA controller.

But SATA is not a memory-mapped bus - in the context of MMIO, the AHCI 
is the bus-master device, not a bridge or level of interconnect. The 
DeviceTree spec[1] clearly defines dma-ranges as an address translation 
between a "parent bus" and a "child bus".

If in the worst case this address-limited interconnect really only 
exists between the AHCI's master interface and everything else in the 
system, then you'll have to describe it explicitly to meet DT's 
expectation of a "bus" (e.g. [2]). Yes, it's a bit clunky, but any 
scheme has its edge cases.

>  From Documentation/devicetree/booting-without-of.txt
> 
> * DMA Bus master
> Optional property:
> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of 
> triplets of
>          (child-bus-address, parent-bus-address, length). Each triplet 
> specified
>          describes a contiguous DMA address range.
>          The dma-ranges property is used to describe the direct memory 
> access (DMA)
>          structure of a memory-mapped bus whose device tree parent can 
> be accessed
>          from DMA operations originating from the bus. It provides a 
> means of
>          defining a mapping or translation between the physical address 
> space of
>          the bus and the physical address space of the parent of the bus.
>          (for more information see the Devicetree Specification)
> 
> * DMA Bus child
> Optional property:
> - dma-ranges: <empty> value. if present - It means that DMA addresses
>          translation has to be enabled for this device.

Disregarding that this was apparently never in ePAPR, so not 
grandfathered in to DTSpec, and effectively nobody ever has actually 
followed it (oh, if only...), note "<empty>" - that still doesn't imply 
that a *non-empty* dma-ranges would be valid on device nodes.

Robin.

[1] https://www.devicetree.org/specifications/
[2] 
https://lore.kernel.org/lkml/20181010120737.30300-20-laurentiu.tudor@nxp.com/

  reply	other threads:[~2020-02-19 15:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 10:49 dma_mask limited to 32-bits with OF platform device Roger Quadros
2020-02-12 11:37 ` Robin Murphy
2020-02-12 12:33   ` Roger Quadros
2020-02-12 14:04     ` Robin Murphy
2020-02-12 17:57       ` Christoph Hellwig
2020-02-17 13:21       ` Christoph Hellwig
2020-02-17 14:54         ` Peter Ujfalusi
2020-02-18  7:26           ` Peter Ujfalusi
2020-02-18  8:28         ` Roger Quadros
2020-02-18 17:22           ` Rob Herring
2020-02-19 14:29             ` Roger Quadros
2020-02-19 15:25               ` Robin Murphy [this message]
2020-02-19 15:40                 ` Roger Quadros
2020-02-26 11:33                 ` Roger Quadros
2020-03-03  8:27                   ` Roger Quadros
2020-03-03 14:06                     ` Robin Murphy
2020-03-03 19:26                       ` Rob Herring
2020-03-04  8:28                         ` Roger Quadros

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=827fa19d-1990-16bc-33f5-fc82ac0d4a8a@arm.com \
    --to=robin.murphy@arm.com \
    --cc=afaerber@suse.de \
    --cc=devicetree@vger.kernel.org \
    --cc=hch@lst.de \
    --cc=hdegoede@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m-karicheri2@ti.com \
    --cc=nm@ti.com \
    --cc=nsekhar@ti.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=rogerq@ti.com \
    --cc=s-anna@ti.com \
    --cc=stefan.wahren@i2se.com \
    --cc=vigneshr@ti.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).