linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Courbot <acourbot@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: "Terje Bergström" <tbergstrom@nvidia.com>,
	"Stephen Warren" <swarren@wwwdotorg.org>,
	dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org, gnurou@gmail.com
Subject: Re: [PATCH 2/2] drm/tegra: Set the DMA mask
Date: Wed, 24 Feb 2016 17:38:09 +0900	[thread overview]
Message-ID: <56CD6BF1.8040107@nvidia.com> (raw)
In-Reply-To: <20160223160440.GE27656@ulmo>

On 02/24/2016 01:04 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Feb 23, 2016 at 03:25:54PM +0900, Alexandre Courbot wrote:
>> The default DMA mask covers a 32 bits address range, but tegradrm can
>> address more than that. Set the DMA mask to the actual addressable range
>> to avoid the use of unneeded bounce buffers.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> Thierry, I am not absolutely sure whether the size is correct and applies
>> to all Tegra generations - please let me know if this needs to be
>> reworked.
>>
>>   drivers/gpu/drm/tegra/drm.c | 1 +
>>   1 file changed, 1 insertion(+)
>
> This kind of depends on whether or not the device is behind an IOMMU.  If
> it is, then the IOMMU DMA MASK would apply, which can be derived from
> the number of address bits that the IOMMU can handle. The SMMU supports
> 32 address bits on Tegra30 and Tegra114, 34 address bits on more recent
> generations.
>
> I think for now it's safer to leave the DMA mask at the default (32 bit)
> to avoid the need to distinguish between IOMMU and non-IOMMU devices.

Leaving it that way makes it (almost) impossible to import buffers on 
TX1. Patch 1 sets the DMA ops to swiotlb, so at least after this we 
actually try to import the buffer. However, any page that is higher than 
the 32 bits range will be bounced. If you are lucky, you won't notice it 
(even though I don't think it is acceptable to bounce data to be 
displayed), but most of the time the swiotlb bounce area will run full 
and import will fail with the following message:

drm drm: swiotlb buffer is full (sz: 294912 bytes)

So we should really try and fix this. The issue is, how do you detect 
whether you are behind a IOMMU? The DCs have an iommus property, but the 
drm device (which does the importing) does not. And when we import a 
buffer into tegradrm, nothing guarantees that it is for display. So far 
I cannot think of a better heuristics than "assume 32 bits on < t124 and 
34 bits afterwards".

  parent reply	other threads:[~2016-02-24  8:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-23  6:25 [PATCH 1/2] drm/tegra: Set DMA ops Alexandre Courbot
2016-02-23  6:25 ` [PATCH 2/2] drm/tegra: Set the DMA mask Alexandre Courbot
2016-02-23 16:04   ` Thierry Reding
2016-02-23 16:18     ` Terje Bergstrom
2016-02-23 16:27       ` Thierry Reding
2016-02-24  8:38     ` Alexandre Courbot [this message]
2016-02-23 15:28 ` [PATCH 1/2] drm/tegra: Set DMA ops Thierry Reding
2016-02-24  8:30   ` Alexandre Courbot

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=56CD6BF1.8040107@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gnurou@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=tbergstrom@nvidia.com \
    --cc=thierry.reding@gmail.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).