All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Tero Kristo <t-kristo@ti.com>
Cc: Roger Quadros <rogerq@ti.com>,
	hch@lst.de, robin.murphy@arm.com, 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: Tue, 10 Mar 2020 08:48:29 -0700	[thread overview]
Message-ID: <20200310154829.GS37466@atomide.com> (raw)
In-Reply-To: <e7df4db7-6fe1-cfa4-841b-ddd395864bb8@ti.com>

* 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.
So yeah I too would prefer a top level dma-ranges property assuming
that works.

I guess there dma-ranges should not be 0xffffffff though if
limited to 2GB :)

Regards,

Tony

  reply	other threads:[~2020-03-10 15:48 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 [this message]
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

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=20200310154829.GS37466@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.