release the buffer, then kernel may
reuse it.
For the "CMA" restricted heap, "struct cma *cma" is a common property,
not just for MediaTek, so put it into "struct restricted_heap" instead of
our private data.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig
ith the ALLOC command
above.
3) MTK_TZCMD_SECMEM_RETRIEVE_SG: If the tee buffer is discrete, this
command can retrieve the detailed PA list from the TEE with which the
kernel will initialize the sg table. Of course, if the tee buffer is
contiguous, the PA will be obtained directly from MTK_TZCMD_SECMEM_Z
the first time.
b) Add a priv_data for each heap, like the special data used by MTK
(such as "TEE session") can be placed in priv_data.
Currently our heap depends on CMA which could only be bool, thus
depend on "TEE=y".
Signed-off-by: Yong Wu
---
drivers/d
check if this is a restricted buffer by sg_dma_is_restricted.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/restricted_heap.c | 102
drivers/dma-buf/heaps/restricted_heap.h | 2 +
2 files changed, 104 insertions(+)
diff --git a/drivers/dma-buf/heaps
Add "struct restricted_heap_ops". For the restricted memory, totally there
are two steps:
a) alloc: Allocate the buffer in kernel;
b) restrict_buf: Restrict/Protect/Secure that buffer.
The "alloc" is mandatory while "restrict_buf" is optional since it may
be part of
Initialize a restricted heap. Currently just add a null heap, Prepare for
the later patches.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 9
drivers/dma-buf/heaps/Makefile | 3 +-
drivers/dma-buf/heaps/restricted_heap.c | 67
Prepare for the restricted heap to reuse, move it out from system_heap.c.
To keep the function name consistent, rename it to sg_dup_table.
Cc: Andrew Morton
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/system_heap.c | 27 +--
include/linux/scatterlist.h | 2
Introduce a FLAG for the restricted memory which means the memory is
protected by TEE or hypervisor, then it's inaccessiable for kernel.
Currently we don't use sg_dma_unmark_restricted, thus this interface
has not been added.
Signed-off-by: Yong Wu
---
include/linux/scatterl
MTK_TZCMD_SECMEM_ZALLOC and MTK_TZCMD_SECMEM_FREE.
Signed-off-by: Yong Wu
---
.../mediatek,dynamic-restricted-region.yaml | 43 +++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-restricted-region.yaml
diff --git
a
nterface, which tries
to make uuid more generic, not working. If there is other way to make
UUID more general, please free to tell me.
v1:
https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong...@mediatek.com/
Base on v6.6-rc1.
Yong Wu (9):
dt-bindings: reser
release the buffer, then kernel may
reuse it.
For the "CMA" restricted heap, "struct cma *cma" is a common property,
not just for MediaTek, so put it into "struct restricted_heap" instead of
our private data.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig
ecure handle"/"secure address". To make the name more general, We call
it "restricted_addr" here. The restricted_addr is a reference to a secure
buffer within TEE. We put it in the sg_dma_address, please see the comment
in code.
Signed-off-by: Yong Wu
---
drivers/dma-buf/he
the first time.
b) Add a priv_data for each heap, like the special data used by MTK
(such as "TEE session") can be placed in priv_data.
Currently our heap depends on CMA which could only be bool, thus
depend on "TEE=y".
Signed-off-by: Yong Wu
---
drivers/d
Add the dma_ops for this restricted heap. For restricted buffer,
cache_ops/mmap are not allowed, thus return EPERM for them.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/restricted_heap.c | 103
1 file changed, 103 insertions(+)
diff --git a/drivers/dma-buf/heaps
mory_alloc.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/restricted_heap.c | 41 -
drivers/dma-buf/heaps/restricted_heap.h | 12
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/restricted_heap.c
b/drivers/dma-buf/heaps/restric
Initialize a restricted heap. Currently just add a null heap, Prepare for
the later patches.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 9
drivers/dma-buf/heaps/Makefile | 3 +-
drivers/dma-buf/heaps/restricted_heap.c | 67
MTK_TZCMD_SECMEM_ZALLOC and MTK_TZCMD_SECMEM_FREE.
Signed-off-by: Yong Wu
---
.../mediatek,dynamic-restricted-region.yaml | 43 +++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-restricted-region.yaml
diff --git
a
face, which tries
to make uuid more generic, not working. If there is other way to make
UUID more general, please free to tell me.
v1:
https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong...@mediatek.com/
Base on v6.6-rc1.
Yong Wu (7):
dt-bindings: reserved-memor
release the buffer, then kernel may
reuse it.
For the "CMA" secure heap, "struct cma *cma" is a common property, not just
for MediaTek, so put it into "struct secure_heap" instead of our private
data.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig
ecure address". The secure_address is a reference to a secure buffer
within TEE. We put it in the sg_dma_address, please see the comment in
code.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/secure_heap.c | 16 +
drivers/dma-buf/heaps/secure_heap.h | 2 +
drivers/dma
time.
b) Add a priv_data for each heap, like the special data used by MTK
(such as "TEE session") can be placed in priv_data.
Currently our heap depends on CMA which could only be bool, thus
depend on "TEE=y".
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig
Add the dma_ops for this secure heap. For secure buffer, cache_ops/mmap
are not allowed, thus return EPERM for them.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/secure_heap.c | 103
1 file changed, 103 insertions(+)
diff --git a/drivers/dma-buf/heaps
ned-off-by: Yong Wu
---
drivers/dma-buf/heaps/secure_heap.c | 39 -
drivers/dma-buf/heaps/secure_heap.h | 11
2 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/secure_heap.c
b/drivers/dma-buf/heaps/secure_heap.c
index e0
MTK_TZCMD_SECMEM_ZALLOC and MTK_TZCMD_SECMEM_FREE.
Signed-off-by: Yong Wu
---
.../mediatek,dynamic-secure-region.yaml | 43 +++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml
diff --git
a
Initialize a secure heap. Currently just add a null heap, Prepare for
the later patches.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 6 +++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/secure_heap.c | 67 +
drivers/dma-buf
D more general, please free to tell me.
v1:
https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong...@mediatek.com/
Base on v6.6-rc1.
Yong Wu (7):
dt-bindings: reserved-memory: Add mediatek,dynamic-secure-region
dma-buf: heaps: Initialize a secure heap
dma-buf: he
Add a normal CMA heap which use the standard cma allocate.
Signed-off-by: Yong Wu
---
Hi Vijay and Jaskaran,
For this heap,
1) It uses sec_heap_buf_ops currently. I guess we cann't use the
cma_heap_buf_ops. since if it is secure buffer, some operations such
as mmap should not be allowed.
.
Meanwhile, this patch adds a "heap_init" pointer, while allows some heap
initialization operations. This case also checks if the CMA range is
ready.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/secure_heap.c | 124 +++-
1 file changed, 122 insertions(+), 2 deletion
Add a binding for describing the secure CMA reserved memory range. The
memory range also will be defined in the TEE firmware. It means the TEE
will be configured with the same address/size that is being set in this
DT node.
Signed-off-by: Yong Wu
---
.../reserved-memory/secure_cma_region.yaml
Add the dma_ops for this secure heap.
a) For secure buffer, cache_ops/mmap are not allowed, thus return
EPERM for them.
b) The secure buffer can't be accessed in kernel, thus it doesn't
have va/dma_address for it. Use the dma_address property to save the
"secure handle".
Si
the ops
of secure_the_memory.
It seems that secure_heap_tee_service_call could be a more general
interface, but it could be a new topic.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/secure_heap.c | 97 +
1 file changed, 97 insertions(+)
diff --git a/drivers/dma-buf/heaps/sec
at it doesn't enter TEE to protect the
buffer, there may be other ways to protect the buffer.
All the MTK chrome projects use this UUID. The UUID is only used in the
kernelspace while userspace never use it. The userspace could allocate the
secure memory via the existing dma-buf ioctl.
Signed-off-b
For the secure memory, there are two steps:
a) Allocate buffers in kernel side;
b) Secure that buffer.
Different heaps may have different buffer allocation methods and
different memory protection methods. Here abstract the memory
allocation and securing operations.
Signed-off-by: Yong Wu
Initialize a secure heap. Currently just add a null heap, Prepare for
the later patches.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 7 +++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/secure_heap.c | 98 +
3 files changed
re is other way to make
UUID more general, please free to tell me.
v1:
https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong...@mediatek.com/
Base on v6.6-rc1.
Yong Wu (8):
dma-buf: heaps: Initialize a secure heap
dma-buf: heaps: secure_heap: Add private heap ops
dma-bu
buffer, then kernel may
reuse it.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 2 +-
drivers/dma-buf/heaps/mtk_secure_heap.c | 121 +++-
2 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps
This adds the binding for describing a CMA memory for MediaTek SVP(Secure
Video Path).
Signed-off-by: Yong Wu
---
.../mediatek,secure_cma_chunkmem.yaml | 42 +++
1 file changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reserved-memory
ned-off-by: Anan Sun
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/mtk_secure_heap.c | 116
1 file changed, 116 insertions(+)
diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c
b/drivers/dma-buf/heaps/mtk_secure_heap.c
index 14c2a16a7164..daf6cf2121a1 100644
--- a/d
Add TEE service call for secure memory allocating/freeing.
Signed-off-by: Anan Sun
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/mtk_secure_heap.c | 69 -
1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c
b/drivers
The TEE probe later than dma-buf heap, and PROBE_DEDER doesn't work
here since this is not a platform driver, therefore initialise the TEE
context/session while we allocate the first secure buffer.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/mtk_secure_heap.c
Initialise a mtk_svp heap. Currently just add a null heap, Prepare for
the later patches.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 8 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/mtk_secure_heap.c | 99 +
3 files
for a pipeline, so it would likely be best for
drivers to import and fill DMA-BUFs allocated by userland
instead of allocating one themselves, but this is still
up for debate.
Signed-off-by: John Stultz
Signed-off-by: T.J. Mercier
Signed-off-by: Yong Wu
[Yong: Fix the checkpatch alignment wa
perly free things.
Signed-off-by: John Stultz
Signed-off-by: T.J. Mercier
Signed-off-by: Yong Wu
[Yong: Just add comment for "minor" and "refcount"]
---
drivers/dma-buf/dma-heap.c | 38 ++
include/linux/dma-heap.h | 6 ++
2 files cha
leanup.
Remove multiple unused includes.
Signed-off-by: T.J. Mercier
Signed-off-by: Yong Wu
[Yong: Just add a comment for "priv" to mute build warning]
---
drivers/dma-buf/dma-heap.c | 29 +++--
include/linux/dma-heap.h | 11 +--
2 files changed, 12 in
-heap: Add proper kref handling on dma-buf heaps
dma-heap: Provide accessors so that in-kernel drivers can allocate
dmabufs from specific heaps
T.J. Mercier (1):
dma-buf: heaps: Deduplicate docs and adopt common format
Yong Wu (6):
dma-buf: heaps: Initialise MediaTek secure heap
dma-buf:
The component requires the compare/release functions, there are so many
copy in current kernel. Just define three common helpers for them.
No functional change.
Signed-off-by: Yong Wu
---
Base on v5.17-rc1
---
.../gpu/drm/arm/display/komeda/komeda_drv.c| 5 -
drivers/gpu/drm/arm
On Thu, 2022-01-13 at 17:10 +0100, Matthias Brugger wrote:
> Hi Hans,
>
> On 13/01/2022 11:15, Hans Verkuil wrote:
> > On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:
> > > Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:
> > > > I
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Reviewed-by: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot
After adding device_link between the IOMMU consumer and smi, the
mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
Acked
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec devices call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Ack
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device calls the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Ack
or rdma device.
CC: CK Hu
Signed-off-by: Yongqiang Niu
Signed-off-by: Yong Wu
(Yong: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync)
Acked-by: Chun-Kuang Hu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device calls the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan
ve it too.
CC: Rick Chang
CC: Xia Jiang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Rick Chang
Reviewed-by: Dafna Hirschfeld
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Acked-by: AngeloGioacchino Del Regno
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c
//lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/
[2] https://lore.kernel.org/patchwork/patch/1086569/
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Acked-by: Joerg Roedel
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/io
it is not allowed to
EXPORT from https://lore.kernel.org/patchwork/patch/1334670/.
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Acked-by: Joerg Roedel
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c| 4
drivers/iommu/mtk_iommu_v1.c | 4
ase.
It's a minor fix, no need add fixes tags.
Signed-off-by: Yong Wu
Acked-by: Joerg Roedel
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c| 2 +-
drivers/iommu/mtk_iommu_v1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iom
return -EINVAL;
}
...
}
Thus, Free the existed fwspec if the master device already has fwspec.
This issue is reported at:
https://lore.kernel.org/linux-mediatek/trinity-7d9ebdc9-4849-4d93-bfb5-429dcb4ee449-1626253158870@3c-app-gmx-bs01/
Reported-by: Frank Wunderlich
Test
sumer connects with from
iommu id in the "iommus=" property.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
Reviewed-by: Evan Green
Acked-by: AngeloGioacchino Del Regno
---
.../bindings/display/mediatek/mediatek,disp.txt | 9 -
.../bindings/media/mediatek,vcod
the consumer and smi-larb into
iommu_add_device from Robin.
3) add DL_FLAG_AUTOREMOVE_CONSUMER even though the smi is built-in from Evan.
4) Remove the shutdown callback in iommu.
v1:
https://lore.kernel.org/linux-iommu/1546318276-18993-1-git-send-email-yong...@mediatek.com/
Yong Wu (12)
On Fri, 2022-01-14 at 15:30 -0600, Stephen Boyd wrote:
> Quoting Yong Wu (2022-01-14 01:06:31)
> > On Wed, 2022-01-12 at 20:25 -0800, Stephen Boyd wrote:
> > > >
> > > > [2.654526] [ cut here ]
> > > > [2.6555
On Wed, 2022-01-12 at 20:25 -0800, Stephen Boyd wrote:
> >
> > [2.654526] [ cut here ]
> > [2.68] refcount_t: addition on 0; use-after-free.
> >
> > After this patch, the aggregate_driver flow looks ok. But our
> > driver
> > still aborts like this:
> >
> > [
On Tue, 2022-01-11 at 16:27 -0800, Stephen Boyd wrote:
> Quoting Yong Wu (2022-01-11 04:22:23)
> > Hi Stephen,
> >
> > Thanks for helping update here.
> >
> > On Thu, 2022-01-06 at 13:45 -0800, Stephen Boyd wrote:
> > > Use an aggregate driver instead
he aggregate device.
>
> Cc: Yong Wu
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Daniel Vetter
> Cc: "Rafael J. Wysocki"
> Cc: Rob Clark
> Cc: Russell King
> Cc: Saravana Kannan
> Signed-off-by: Stephen Boyd
When I test this on mt8195 which have two
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --
2
After adding device_link between the IOMMU consumer and smi, the
mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
Acked
After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that function, use pm_runtime_disable instead.
meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks,
rename it from the _pm to _clk.
No functional change.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong
.
No functional change.
CC: Tiffany Lin
CC: Yunfei Dong
Signed-off-by: Yong Wu
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 8 +---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 9 +
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 3 +--
3 files
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Ack
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
or rdma device.
CC: CK Hu
Signed-off-by: Yongqiang Niu
Signed-off-by: Yong Wu
(Yong: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync)
Acked-by: Chun-Kuang Hu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8 +++-
driv
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Rev
t too.
CC: Rick Chang
CC: Xia Jiang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Rick Chang
Reviewed-by: Dafna Hirschfeld
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 45 +--
.../media/platform/mtk
//lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/
[2] https://lore.kernel.org/patchwork/patch/1086569/
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/iommu/mtk_iommu.c| 30 ++
drivers/io
it is not allowed to
EXPORT from https://lore.kernel.org/patchwork/patch/1334670/.
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/iommu/mtk_iommu.c| 4
drivers/iommu/mtk_iommu_v1.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/iommu
ase.
It's a minor fix, no need add fixes tags.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c| 2 +-
drivers/iommu/mtk_iommu_v1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d837adfd1da5..8f5
return -EINVAL;
}
...
}
Thus, Free the existed fwspec if the master device already has fwspec.
This issue is reported at:
https://lore.kernel.org/linux-mediatek/trinity-7d9ebdc9-4849-4d93-bfb5-429dcb4ee449-1626253158870@3c-app-gmx-bs01/
Reported-by: Frank Wunderlich
Tested-b
sumer connects with from
iommu id in the "iommus=" property.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
Reviewed-by: Evan Green
---
.../bindings/display/mediatek/mediatek,disp.txt | 9 -
.../devicetree/bindings/media/mediatek-jpeg-decoder.yaml | 9 -
.../devi
Evan.
4) Remove the shutdown callback in iommu.
v1:
https://lore.kernel.org/linux-iommu/1546318276-18993-1-git-send-email-yong...@mediatek.com/
Yong Wu (14):
dt-binding: mediatek: Get rid of mediatek, larb for multimedia HW
iommu/mediatek-v1: Free the existed fwspec if the master dev alre
On Mon, 2021-10-18 at 09:13 +0200, Dafna Hirschfeld wrote:
>
> On 16.10.21 04:23, Yong Wu wrote:
> > On Mon, 2021-10-11 at 14:36 +0200, Dafna Hirschfeld wrote:
> > >
> > > On 29.09.21 03:37, Yong Wu wrote:
> > > > MediaTek IOMMU-SMI diagram is li
On Mon, 2021-10-11 at 14:36 +0200, Dafna Hirschfeld wrote:
>
> On 29.09.21 03:37, Yong Wu wrote:
> > MediaTek IOMMU-SMI diagram is like below. all the consumer connect
> > with
> > smi-larb, then connect with smi-common.
> >
> > M4U
On Thu, 2021-09-30 at 12:57 +0200, Dafna Hirschfeld wrote:
>
> On 30.09.21 05:28, Yong Wu wrote:
> > Hi Dafna,
> >
> > Thanks very much for the review.
> >
> > On Wed, 2021-09-29 at 14:13 +0200, Dafna Hirschfeld wrote:
> > >
> > > On 29.
On Wed, 2021-09-29 at 18:33 +0200, Dafna Hirschfeld wrote:
>
> On 29.09.21 03:37, Yong Wu wrote:
> > Prepare for adding device_link.
> >
> > The iommu consumer should use device_link to connect with the
> > smi-larb(supplier). then the smi-larb should run before t
Hi Dafna,
Thanks very much for the review.
On Wed, 2021-09-29 at 14:13 +0200, Dafna Hirschfeld wrote:
>
> On 29.09.21 03:37, Yong Wu wrote:
> > MediaTek IOMMU has already added the device_link between the
> > consumer
> > and smi-larb device. If th
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --
2
After adding device_link between the IOMMU consumer and smi, the
mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
Acked
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Ack
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
or rdma device.
CC: CK Hu
Signed-off-by: Yongqiang Niu
Signed-off-by: Yong Wu
(Yong: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync)
Acked-by: Chun-Kuang Hu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8 +++-
driv
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Rev
t too.
CC: Rick Chang
CC: Xia Jiang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Rick Chang
Reviewed-by: Dafna Hirschfeld
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 45 +--
.../media/platform/mtk
ed-by: Tomasz Figa
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/iommu/mtk_iommu.c| 22 ++
drivers/iommu/mtk_iommu_v1.c | 20 +++-
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu
it is not allowed to
EXPORT from https://lore.kernel.org/patchwork/patch/1334670/.
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/iommu/mtk_iommu.c| 2 +-
drivers/iommu/mtk_iommu_v1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a
return -EINVAL;
}
...
}
Thus, Free the existed fwspec if the master device already has fwspec.
This issue is reported at:
https://lore.kernel.org/linux-mediatek/trinity-7d9ebdc9-4849-4d93-bfb5-429dcb4ee449-1626253158870@3c-app-gmx-bs01/
Reported-by: Frank Wunderlich
Signed
sumer connects with from
iommu id in the "iommus=" property.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
Reviewed-by: Evan Green
---
.../bindings/display/mediatek/mediatek,disp.txt | 9 -
.../devicetree/bindings/media/mediatek-jpeg-decoder.yaml | 9 -
.../devi
5.2-rc1.
2) Move adding device_link between the consumer and smi-larb into
iommu_add_device from Robin.
3) add DL_FLAG_AUTOREMOVE_CONSUMER even though the smi is built-in from Evan.
4) Remove the shutdown callback in iommu.
v1:
https://lore.kernel.org/linux-iommu/1546318276-18993-1
t too.
CC: Rick Chang
CC: Xia Jiang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Rick Chang
Reviewed-by: Dafna Hirschfeld
Tested-by: Dafna Hirschfeld # on mt8173
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 45 +--
.../media/platform/mtk-jpeg/mtk_jpeg_c
1 - 100 of 129 matches
Mail list logo
