Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Randy Li]

On 01/18/2018 10:25 PM, JeffyChen wrote:

Hi Robin,

On 01/18/2018 08:27 PM, Robin Murphy wrote:




Is it worth using the clk_bulk_*() APIs for this? At a glance, most of
the code being added here appears to duplicate what those functions
already do (but I'm no clk API expert, for sure).
right, i think it's doable, the clk_bulk APIs are very helpful. i think 
we didn't use that is because this patch were wrote for the chromeos 4.4 
kernel, which doesn't have clk_bulk yet:)


will do it in the next version, thanks.
Also the power domain driver could manage the clocks as well, I would 
suggest to use pm_runtime_*.


Robin.




___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Randy Li

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Randy Li]

On 01/22/2018 12:09 PM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 10:15 AM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 09:18 AM, Randy Li wrote:



Also the power domain driver could manage the clocks as well, I would
suggest to use pm_runtime_*.


actually the clocks required by pm domain may not be the same as what we
want to control here, there might be some clocks only be needed when
accessing mmu registers.

but i'm not very sure about that, will confirm it with Simon Xue.


confirmed with Simon, there might be some iommus don't have a pd, and 
We use the pd to control the NIU node(not on upstream), without a pd or 
fake pd, none of the platform would work.

the CONFIG_PM could be disabled.I am hard to believe a modern platform can work 
without that.

so it might be better to control clocks in iommu driver itself.I won't insist how the version of the iommu patch on the upstream, I 

just post an idea here.
The version for kernel 4.4 is under internal review, the implementation 
has been modified many times.


I would suggest the managing clocks in pd is a more easy way and don't 
need to spare those thing in two places.



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Randy Li

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] [TEST]: media: vb2: reverse DMA addr of each plane

[Randy Li]

With the default iova and dma-iommu driver, the starting
address of a new buffer would be at lower address than
the previous one.

This patch can solve this problem simply, but I want
a way to control the address direction of the IOMMU/IOVA.

The reason why we(ayaka and I) need to do this is simple,
some devices want a contiguous memory for its pixel data.
But with the single plane buffer, there is not a properly way
to export its buffer offsets with the userspace,
since their bytesperline and offset are not full related
to the picture width or height. You can find more detail
in the previous mail.

Besides, this patch won't solve all the problem, if you
don't disable the size_aligned of the iova driver or
there would be a gap between the plane 0 and plane 1.

This patch is used for showing the problem we met not
for merging.

Signed-off-by: Randy Li 
---
 drivers/media/common/videobuf2/videobuf2-core.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index 15b6b9c0a2e4..6762d1547e49 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -204,11 +204,11 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
 * Allocate memory for all planes in this buffer
 * NOTE: mmapped areas should be page aligned
 */
-   for (plane = 0; plane < vb->num_planes; ++plane) {
-   unsigned long size = PAGE_ALIGN(vb->planes[plane].length);
+   for (plane = vb->num_planes; plane > 0; --plane) {
+   unsigned long size = PAGE_ALIGN(vb->planes[plane - 1].length);
 
mem_priv = call_ptr_memop(vb, alloc,
-   q->alloc_devs[plane] ? : q->dev,
+   q->alloc_devs[plane - 1] ? : q->dev,
q->dma_attrs, size, q->dma_dir, q->gfp_flags);
if (IS_ERR_OR_NULL(mem_priv)) {
if (mem_priv)
@@ -217,15 +217,15 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
}
 
/* Associate allocator private data with this plane */
-   vb->planes[plane].mem_priv = mem_priv;
+   vb->planes[plane - 1].mem_priv = mem_priv;
}
 
return 0;
 free:
/* Free already allocated memory if one of the allocations failed */
-   for (; plane > 0; --plane) {
-   call_void_memop(vb, put, vb->planes[plane - 1].mem_priv);
-   vb->planes[plane - 1].mem_priv = NULL;
+   for (; plane < vb->num_planes; plane++) {
+   call_void_memop(vb, put, vb->planes[plane].mem_priv);
+   vb->planes[plane].mem_priv = NULL;
}
 
return ret;
-- 
2.20.1



___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu