All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
From: mark.yao@rock-chips.com (Mark yao)
To: linux-arm-kernel@lists.infradead.org
Subject: [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.

-- 
?ark Yao

WARNING: multiple messages have this Message-ID (diff)
From: Mark yao <mark.yao@rock-chips.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: dri-devel@lists.freedesktop.org, zwl@rock-chips.com,
	Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, Daniel Kurtz <djkurtz@chromium.org>,
	tfiga@chromium.org, linux-rockchip@lists.infradead.org,
	Rob Clark <robdclark@gmail.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	xw@rock-chips.com, dkm@rock-chips.com,
	sandy.huang@rock-chips.com, linux-arm-kernel@lists.infradead.org,
	Heiko Stuebner <heiko@sntech.de>
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



  reply	other threads:[~2015-06-19  2:50 UTC|newest]

Thread overview: 27+ 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 ` Mark Yao
2015-06-18  7:49 ` Mark Yao
2015-06-18  7:49 ` [PATCH 1/6] drm/rockchip: import dma_buf to gem Mark Yao
2015-06-18  7:49   ` Mark Yao
2015-06-18  7:49   ` Mark Yao
2015-06-18 10:57   ` Russell King - ARM Linux
2015-06-18 10:57     ` Russell King - ARM Linux
2015-06-18 10:57     ` Russell King - ARM Linux
2015-06-19  2:50     ` Mark yao [this message]
2015-06-19  2:50       ` Mark yao
2015-06-19  2:50       ` Mark yao
2015-06-18  7:49 ` [PATCH 2/6] drm/rockchip: vop: optimize virtual stride calculate Mark Yao
2015-06-18  7:49   ` Mark Yao
2015-06-18  7:49   ` Mark Yao
2015-06-18  7:49 ` [PATCH 3/6] drm/rockchip: vop: fix yuv plane support Mark Yao
2015-06-18  7:49   ` Mark Yao
2015-06-18  7:49   ` Mark Yao
2015-06-18  7:49 ` [PATCH 4/6] drm/rockchip: vop: support plane scale Mark Yao
2015-06-18  7:49   ` Mark Yao
2015-06-18  7:49   ` 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:53   ` Mark Yao
2015-06-18  7:53   ` Mark Yao
2015-06-18  7:55 ` [PATCH 6/6] drm/rockchip: vop: default enable win2/3 area0 bit Mark Yao
2015-06-18  7:55   ` Mark Yao
2015-06-18  7:55   ` 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 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.