Hi Baolu,
On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 9/2/19 4:37 PM, Janusz Krzysztofik wrote:
> >> I am not saying that keeping data is not acceptable. I just want to
> >> check whether there are any other solutions.
> > Then reverting 458b7c8e0dde and appl
MediaTek IOMMU block diagram always like below:
M4U
|
smi-common
|
-
| | ...
| |
larb1 larb2
| |
vdec venc
All the consumer connect with smi-larb, then connect with smi-common.
MediaTek IOMMU don't have its powe
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.
And IOMMU also know which larb this consumer connec
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is
ready, then all the iommu consumer always is after the smi driver.
When there is no this patch, if some c
Normally, If the smi-larb HW need work, we should enable the smi-common
HW power and clock firstly.
This patch adds device-link between the smi-larb dev and the smi-common
dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
(smi-common-dev) will be called automatically.
Also, A
MediaTek IOMMU don't have its power-domain. all the consumer connect
with smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should en
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Rick Chang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
drivers/media/platform/mtk-j
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
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
drivers/media/platfor
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
---
drivers/memory/mtk-smi.c | 14 -
MediaTek IOMMU should wait for smi larb which need wait for the
power domain(mtk-scpsys.c) and the multimedia ccf who both are
module init. Thus, subsys_initcall for MediaTek IOMMU is not helpful.
Switch to builtin_platform_driver.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c| 31 +--
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
---
drivers/gp
From: Yongqiang Niu
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device which has linked
with larb0, then it will enable the correpsonding larb0 clock
automatically by the device link.
Signed-off-by: Yongqiang Niu
Signed-off-b
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
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
.../media/platform/m
smi-larb driver should run after smi-common, Use device_is_bound to confirm
whether smicommon driver is ready.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/m
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 | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/arm64/boo
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/arm/boot/dts/mt2701.dtsi | 1 -
arch/arm/boot/dts/mt7623.dtsi | 1 -
2 files changed, 2 deletions(-)
diff --git a/arc
Remove and from being included
directly as part of the include/linux/of_pci.h, and remove
superfluous declaration of struct of_phandle_args.
Move users of include to include
and directly rather than rely on both being
included transitively through .
Signed-off-by: Krzysztof Wilczynski
---
On Tue, Aug 20, 2019 at 07:42:25PM -0700, Sai Praneeth Prakhya wrote:
> + /*
> + * iommu_domain_alloc() takes "struct bus_type" as an argument which is
> + * a member in "struct device". Changing a group's default domain type
> + * deals at iommu_group level rather than device le
On Sat, Aug 24, 2019 at 03:28:45PM +0200, Uwe Kleine-König wrote:
> Currently of_for_each_phandle ignores the cell_count parameter when a
> cells_name is given. I intend to change that and let the iterator fall
> back to a non-negative cell_count if the cells_name property is missing
> in the refer
On Tue, Sep 03, 2019 at 02:50:56PM +0800, YueHaibing wrote:
> If CONFIG_PCI_ATS is not set, building fails:
>
> drivers/iommu/arm-smmu-v3.c: In function arm_smmu_ats_supported:
> drivers/iommu/arm-smmu-v3.c:2325:35: error: struct pci_dev has no member
> named ats_cap; did you mean msi_cap?
> re
Hi all, sorry for the long read, I kept it as short as possible.
So, the wrapper around the PCIe block available on the Raspberry Pi 4 has a bug
preventing it from accessing anything beyond the first 3G of ram [1]. I'm
trying to figure out the best way to integrate this upstream.
Note that the on
From: Chris Wilson
[ Upstream commit 9eed17d37c77171cf5ffb95c4257f87df3cd4c8f ]
Since the cached32_node is allowed to be advanced above dma_32bit_pfn
(to provide a shortcut into the limited range), we need to be careful to
remove the to be freed node if it is the cached32_node.
[ 48.43] B
On Tue, Sep 03, 2019 at 01:30:59PM +0200, Krzysztof Wilczynski wrote:
> Remove and from being included
> directly as part of the include/linux/of_pci.h, and remove
> superfluous declaration of struct of_phandle_args.
>
> Move users of include to include
> and directly rather than rely on both
Michael Ellerman writes:
> On Tue, 2019-08-06 at 04:49:14 UTC, Thiago Jung Bauermann wrote:
>> powerpc is also going to use this feature, so put it in a generic location.
>>
>> Signed-off-by: Thiago Jung Bauermann
>> Reviewed-by: Thomas Gleixner
>> Reviewed-by: Christoph Hellwig
>
> Series
On Mon 02 Sep 13:07 PDT 2019, Christoph Hellwig wrote:
> Remoteproc started using dma_declare_coherent_memory recently, which is
> a bad idea from drivers, and the maintainers agreed to fix that. But
> until that is fixed only allow building the driver built in so that we
> can remove the dma_dec
On 9/2/19 9:03 AM, Christoph Hellwig wrote:
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index b8808677ae1d..f9dd4cb6e4b3 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -299,8 +299,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_
(Now with correct address for Juergen)
On 9/3/19 6:15 PM, Boris Ostrovsky wrote:
> On 9/2/19 9:03 AM, Christoph Hellwig wrote:
>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>> index b8808677ae1d..f9dd4cb6e4b3 100644
>> --- a/drivers/xen/swiotlb-xen.c
>> +++ b/drivers/xen/sw
Thiago Jung Bauermann [bauer...@linux.ibm.com] wrote:
> [ Some people didn't receive all the patches in this series, even though
> the linuxppc-dev list did so trying to send again. This is exactly the
> same series I posted yesterday. Sorry for the clutter. ]
>
> This series contains prelimin
Use kzfree instead of memset() + kfree().
Signed-off-by: zhong jiang
---
drivers/staging/rtl8723bs/core/rtw_security.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c
b/drivers/staging/rtl8723bs/core/rtw_security.c
index 979056
Use kzfree instead of memset() + kfree().
Signed-off-by: zhong jiang
---
drivers/iommu/fsl_pamu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index cde281b..ca6d147 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drive
Use kzfree instead of memset() + kfree().
Signed-off-by: zhong jiang
---
drivers/crypto/marvell/hash.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 0f0ac85..a2b35fb 100644
--- a/drivers/crypto/marvell/ha
th the help of Coccinelle. We find some place to replace.
@@
expression M, S;
@@
- memset(M, 0, S);
- kfree(M);
+ kzfree(M);
zhong jiang (3):
crypto: marvell: Use kzfree rather than its implementation
iommu/pamu: Use kzfree rather than its implementation
Staging: rtl8723bs: Use kzfree rat
Hi Joerg,
Thanks a lot! for the review. I highly appreciate for sparing your time to
review the patch :)
> On Tue, Aug 20, 2019 at 07:42:25PM -0700, Sai Praneeth Prakhya wrote:
> > + /*
> > +* iommu_domain_alloc() takes "struct bus_type" as an argument which
> is
> > +* a member in "st
Hi,
On 9/4/19 11:09 AM, Prakhya, Sai Praneeth wrote:
Hi Joerg,
Thanks a lot! for the review. I highly appreciate for sparing your time to
review the patch :)
On Tue, Aug 20, 2019 at 07:42:25PM -0700, Sai Praneeth Prakhya wrote:
+ /*
+* iommu_domain_alloc() takes "struct bus_ty
Hi, Yong,
I have inline comment below.
> 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
> Signed-off-by: Yong Wu
35 matches
Mail list logo