From: Tony Lindgren <tony@atomide.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Roger Quadros <rogerq@ti.com>, Tero Kristo <t-kristo@ti.com>,
hch@lst.de, robh+dt@kernel.org, nm@ti.com, nsekhar@ti.com,
linux-omap@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: dts: dra7: Add bus_dma_limit for L3 bus
Date: Wed, 11 Mar 2020 08:49:09 -0700 [thread overview]
Message-ID: <20200311154909.GX37466@atomide.com> (raw)
In-Reply-To: <e031b768-8fb8-ce62-a644-69925757cbc6@arm.com>
* Robin Murphy <robin.murphy@arm.com> [200311 15:48]:
> On 11/03/2020 3:23 pm, Tony Lindgren wrote:
> > * Roger Quadros <rogerq@ti.com> [200311 07:21]:
> > >
> > >
> > > On 10/03/2020 17:48, Tony Lindgren wrote:
> > > > * Tero Kristo <t-kristo@ti.com> [200310 14:46]:
> > > > > On 10/03/2020 13:53, Roger Quadros wrote:
> > > > > > The L3 interconnect can access only 32-bits of address.
> > > > > > Add the dma-ranges property to reflect this limit.
> > > > > >
> > > > > > This will ensure that no device under L3 is
> > > > > > given > 32-bit address for DMA.
> > > > > >
> > > > > > Issue was observed only with SATA on DRA7-EVM with 4GB RAM
> > > > > > and CONFIG_ARM_LPAE enabled. This is because the controller
> > > > > > can perform 64-bit DMA and was setting the dma_mask to 64-bit.
> > > > > >
> > > > > > Setting the correct bus_dma_limit fixes the issue.
> > > > >
> > > > > This seems kind of messy to modify almost every DT node because of this....
> > > > > Are you sure this is the only way to get it done? No way to modify the sata
> > > > > node only which is impacted somehow?
> > > > >
> > > > > Also, what if you just pass 0xffffffff to the dma-ranges property? That
> > > > > would avoid modifying every node I guess.
> > > >
> > > > Also, I think these interconnects are not limited to 32-bit access.
> > >
> > > But from Table 2-1. L3_MAIN Memory Map
> > >
> > > Start address 0x0000_0000
> > > End address 0xFFFF_FFFF
> > >
> > > So it is 32-bit limit, right?
> >
> > Hmm so what war Robin saying earlier that DMA access seems to be
> > limited to lower 2GB only though?
>
> That's the lower 2GB *of DRAM*, which occupies the upper 2GB of the L3
> memory map ;)
OK thanks for clarifying it.
Regards,
Tony
prev parent reply other threads:[~2020-03-11 15:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 11:53 [PATCH] ARM: dts: dra7: Add bus_dma_limit for L3 bus Roger Quadros
2020-03-10 14:45 ` Tero Kristo
2020-03-10 15:48 ` Tony Lindgren
2020-03-10 16:16 ` Robin Murphy
2020-03-11 7:13 ` Roger Quadros
2020-03-11 10:28 ` Roger Quadros
2020-03-11 12:25 ` Robin Murphy
2020-03-11 7:20 ` Roger Quadros
2020-03-11 15:23 ` Tony Lindgren
2020-03-11 15:47 ` Robin Murphy
2020-03-11 15:49 ` Tony Lindgren [this message]
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=20200311154909.GX37466@atomide.com \
--to=tony@atomide.com \
--cc=devicetree@vger.kernel.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rogerq@ti.com \
--cc=t-kristo@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 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.