From: Mark yao <mark.yao@rock-chips.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: zwl@rock-chips.com, linux-kernel@vger.kernel.org,
tfiga@chromium.org, linux-rockchip@lists.infradead.org,
dri-devel@lists.freedesktop.org, xw@rock-chips.com,
dkm@rock-chips.com, sandy.huang@rock-chips.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/6] drm/rockchip: import dma_buf to gem
Date: Fri, 19 Jun 2015 10:50:54 +0800 [thread overview]
Message-ID: <5583838E.7080001@rock-chips.com> (raw)
In-Reply-To: <20150618105715.GJ7557@n2100.arm.linux.org.uk>
Thanks Russell
On 2015年06月18日 18:57, Russell King - ARM Linux wrote:
> This is wrong.
>
> First, if you can only cope with a single scatterlist entry, you need to
> enforce that. You can do that in your gem_prime_import_sg_table() method
> by checking sgt->nents.
I'm confuse that how to get coherent iova address from nocoherent
scatterlist with iommu.
I saw the arm_iommu_map_sg, it says that:
The scatter gather list elements are merged together (if
possible) and
tagged with the appropriate dma address and length.
I guess the map_sg maybe merge scatterlist into coherent iova address,
but I don't know how to
check the "if possible", and the sgt->nents not be 1 when already map to
coherent iova address.
checking sgt-nents = 1 can sure that iova is coherent, but when coherent
iova address from
nocoherent scatterlist, I think sgt->nents maybe greater than 1, is
there a method can deal it?
All above is my guess, maybe wrong, I only tested it with CMA buffer import.
> Secondly, you're mapping an already mapped scatterlist - scatterlists
> are mapped by the exporter inside dma_buf_map_attachment() for your
> device.
Right, found the dma_map_sg on dma_buf_map_attachment().
>
> Thirdly, I hate drm_gem_prime_import() being used on ARM... it forces
> drivers to do something very buggy: the DMA buffer is mapped for DMA
> when the buffer is imported. If the buffer is a write-combine or cached
> buffer, writes to the buffer after the import will not become visible to
> the display hardware until sometime later (when they're evicted from the
> caches and/or pushed out of the bus structure.) The DMA mapping should
> be performed as close to the start of DMA as possible. However, this is
> a long-standing issue I have with dma_buf itself and is not something you
> should be too concerned with in your patch. Just bear it in mind if you
> start to see corruption of imported buffers - the answer is not more
> dma_map_sg() calls, but to get dma_buf fixed.
Yeah, Got it.
--
Mark Yao
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-06-19 2:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 7:49 [PATCH 0/6] drm/rockchip: support yuv overlay and plane scale Mark Yao
2015-06-18 7:49 ` [PATCH 1/6] drm/rockchip: import dma_buf to gem Mark Yao
2015-06-18 10:57 ` Russell King - ARM Linux
2015-06-19 2:50 ` Mark yao [this message]
2015-06-18 7:49 ` [PATCH 2/6] drm/rockchip: vop: optimize virtual stride calculate Mark Yao
2015-06-18 7:49 ` [PATCH 3/6] drm/rockchip: vop: fix yuv plane support Mark Yao
2015-06-18 7:49 ` [PATCH 4/6] drm/rockchip: vop: support plane scale Mark Yao
2015-06-18 7:53 ` [PATCH 5/6] drm/rockchip: vop: switch cursor plane to window 3 Mark Yao
2015-06-18 7:55 ` [PATCH 6/6] drm/rockchip: vop: default enable win2/3 area0 bit Mark Yao
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=5583838E.7080001@rock-chips.com \
--to=mark.yao@rock-chips.com \
--cc=dkm@rock-chips.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=sandy.huang@rock-chips.com \
--cc=tfiga@chromium.org \
--cc=xw@rock-chips.com \
--cc=zwl@rock-chips.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