Currenly masters can not indicate its special dma-ranges. Prepare
for vcodec. some vcodec end address is address + size, if our size
is 4G, the end address may be 0x2_0000_0000. and the
register is u32, then it may get zero. thus add a gap(8M) for
all the regions.
Signed-off-by: Yong Wu <[email protected]>
---
drivers/iommu/mtk_iommu.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index e4b8c07d4dbd..dd63d9994133 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -304,15 +304,15 @@ static LIST_HEAD(m4ulist); /* List all the M4U HWs */
#define for_each_m4u(data, head) list_for_each_entry(data, head, list)
static const struct mtk_iommu_iova_region single_domain[] = {
- {.iova_base = 0, .size = SZ_4G},
+ {.iova_base = 0, .size = SZ_4G - SZ_8M},
};
static const struct mtk_iommu_iova_region mt8192_multi_dom[] = {
- { .iova_base = 0x0, .size = SZ_4G}, /* 0 ~ 4G */
+ { .iova_base = 0x0, .size = SZ_4G - SZ_8M}, /* 0 ~ 4G, 8M as a gap. */
#if IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT)
- { .iova_base = SZ_4G, .size = SZ_4G}, /* 4G ~ 8G */
- { .iova_base = SZ_4G * 2, .size = SZ_4G}, /* 8G ~ 12G */
- { .iova_base = SZ_4G * 3, .size = SZ_4G}, /* 12G ~ 16G */
+ { .iova_base = SZ_4G, .size = SZ_4G - SZ_8M}, /* 4G ~ 8G */
+ { .iova_base = SZ_4G * 2, .size = SZ_4G - SZ_8M}, /* 8G ~ 12G */
+ { .iova_base = SZ_4G * 3, .size = SZ_4G - SZ_8M}, /* 12G ~ 16G */
{ .iova_base = 0x240000000ULL, .size = 0x4000000}, /* CCU0 */
{ .iova_base = 0x244000000ULL, .size = 0x4000000}, /* CCU1 */
--
2.18.0
Il 13/01/23 07:01, Yong Wu ha scritto:
> Currenly masters can not indicate its special dma-ranges. Prepare
> for vcodec. some vcodec end address is address + size, if our size
> is 4G, the end address may be 0x2_0000_0000. and the
> register is u32, then it may get zero. thus add a gap(8M) for
> all the regions.
>
> Signed-off-by: Yong Wu <[email protected]>
I definitely agree on the fact that we do *need* this series... but this
particular commit looks like a hack.
I'm not convinced: I have a hunch that this one will sooner or later backfire
on us and break things again... at the same time, I'm not sure how to do this
properly at this point (I didn't do any research, anyway).
Ideas?
Regards,
Angelo
On Mon, 2023-01-16 at 10:46 +0100, AngeloGioacchino Del Regno wrote:
> Il 13/01/23 07:01, Yong Wu ha scritto:
> > Currenly masters can not indicate its special dma-ranges. Prepare
> > for vcodec. some vcodec end address is address + size, if our size
> > is 4G, the end address may be 0x2_0000_0000. and the
> > register is u32, then it may get zero. thus add a gap(8M) for
> > all the regions.
> >
> > Signed-off-by: Yong Wu <[email protected]>
>
> I definitely agree on the fact that we do *need* this series...
Thanks very much for your review.
> but this particular commit looks like a hack.
>
> I'm not convinced: I have a hunch that this one will sooner or later
> backfire
> on us and break things again... at the same time, I'm not sure how to
> do this
> properly at this point (I didn't do any research, anyway).
I got a real vcodec issue described in the commit message. As you may
see in the vcodec's dt-binding example[1/10] or the dts node[9/10],
their length is 0xfff00000 that means they use 1M as the gap. Vcodec
use this for a long time. After this patchset, this property is unused,
then I have to take care of this in the iommu, therefore this patch is
required, and I just give a bigger gap(8M) here.
>
> Ideas?
>
> Regards,
> Angelo
>
On Mon, 2023-01-16 at 10:46 +0100, AngeloGioacchino Del Regno wrote:
> Il 13/01/23 07:01, Yong Wu ha scritto:
> > Currenly masters can not indicate its special dma-ranges. Prepare
> > for vcodec. some vcodec end address is address + size, if our size
> > is 4G, the end address may be 0x2_0000_0000. and the
> > register is u32, then it may get zero. thus add a gap(8M) for
> > all the regions.
> >
> > Signed-off-by: Yong Wu <[email protected]>
>
> I definitely agree on the fact that we do *need* this series...
Thanks very much for your review.
> but this particular commit looks like a hack.
>
> I'm not convinced: I have a hunch that this one will sooner or later
> backfire
> on us and break things again... at the same time, I'm not sure how to
> do this
> properly at this point (I didn't do any research, anyway).
I got a real vcodec issue described in the commit message. As you may
see in the vcodec's dt-binding example[1/10] or the dts node[9/10],
their length is 0xfff00000 that means they use 1M as the gap. Vcodec
use this for a long time. After this patchset, this property is unused,
then I have to take care this in the iommu, therefore this patch is
required, and I just give a bigger gap(8M) here.
>
> Ideas?
>
> Regards,
> Angelo
>