* [PATCH v4 14/18] iommu/mediatek: Fix VLD_PA_RANGE register backup when suspend
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
mode support for mt2712. this patch add it.
Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 2 ++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 1a87a1d..c3b4325 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -721,6 +721,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
reg->ivrp_paddr = readl_relaxed(base + REG_MMU_IVRP_PADDR);
+ reg->vld_pa_range = readl_relaxed(base + REG_MMU_VLD_PA_RNG);
clk_disable_unprepare(data->bclk);
return 0;
}
@@ -745,6 +746,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
+ writel_relaxed(reg->vld_pa_range, base + REG_MMU_VLD_PA_RNG);
if (m4u_dom)
writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
base + REG_MMU_PT_BASE_ADDR);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 6385dec..17996e0 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -33,6 +33,7 @@ struct mtk_iommu_suspend_reg {
u32 int_control0;
u32 int_main_control;
u32 ivrp_paddr;
+ u32 vld_pa_range;
};
enum mtk_iommu_plat {
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 12/18] memory: mtk-smi: Invoke pm runtime_callback to enable clocks
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
This patch only move the clk_prepare_enable and config_port into the
runtime suspend/resume callback. It doesn't change the code content
and sequence.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
(SMI_BUS_SEL need to be restored after smi-common resume every time.)
Also it gives a chance to get rid of mtk_smi_larb_get/put which could
be a next topic.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/memory/mtk-smi.c | 113 ++++++++++++++++++++++++++++++-----------------
1 file changed, 72 insertions(+), 41 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index bced778..ee6165e 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -86,17 +86,13 @@ struct mtk_smi_larb { /* larb: local arbiter */
u32 *mmu;
};
-static int mtk_smi_enable(const struct mtk_smi *smi)
+static int mtk_smi_clk_enable(const struct mtk_smi *smi)
{
int ret;
- ret = pm_runtime_get_sync(smi->dev);
- if (ret < 0)
- return ret;
-
ret = clk_prepare_enable(smi->clk_apb);
if (ret)
- goto err_put_pm;
+ return ret;
ret = clk_prepare_enable(smi->clk_smi);
if (ret)
@@ -118,59 +114,28 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
clk_disable_unprepare(smi->clk_smi);
err_disable_apb:
clk_disable_unprepare(smi->clk_apb);
-err_put_pm:
- pm_runtime_put_sync(smi->dev);
return ret;
}
-static void mtk_smi_disable(const struct mtk_smi *smi)
+static void mtk_smi_clk_disable(const struct mtk_smi *smi)
{
clk_disable_unprepare(smi->clk_gals1);
clk_disable_unprepare(smi->clk_gals0);
clk_disable_unprepare(smi->clk_smi);
clk_disable_unprepare(smi->clk_apb);
- pm_runtime_put_sync(smi->dev);
}
int mtk_smi_larb_get(struct device *larbdev)
{
- struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
- const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
- struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
- int ret;
+ int ret = pm_runtime_get_sync(larbdev);
- /* Enable the smi-common's power and clocks */
- ret = mtk_smi_enable(common);
- if (ret)
- return ret;
-
- /* Enable the larb's power and clocks */
- ret = mtk_smi_enable(&larb->smi);
- if (ret) {
- mtk_smi_disable(common);
- return ret;
- }
-
- /* Configure the iommu info for this larb */
- larb_gen->config_port(larbdev);
-
- return 0;
+ return (ret < 0) ? ret : 0;
}
EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
void mtk_smi_larb_put(struct device *larbdev)
{
- struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
- struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
-
- /*
- * Don't de-configure the iommu info for this larb since there may be
- * several modules in this larb.
- * The iommu info will be reset after power off.
- */
-
- mtk_smi_disable(&larb->smi);
- mtk_smi_disable(common);
+ pm_runtime_put_sync(larbdev);
}
EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
@@ -384,12 +349,52 @@ static int mtk_smi_larb_remove(struct platform_device *pdev)
return 0;
}
+static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+ const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
+ int ret;
+
+ /* Power on smi-common. */
+ ret = pm_runtime_get_sync(larb->smi_common_dev);
+ if (ret < 0) {
+ dev_err(dev, "Failed to pm get for smi-common(%d).\n", ret);
+ return ret;
+ }
+
+ ret = mtk_smi_clk_enable(&larb->smi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enable clock(%d).\n", ret);
+ pm_runtime_put_sync(larb->smi_common_dev);
+ return ret;
+ }
+
+ /* Configure the basic setting for this larb */
+ larb_gen->config_port(dev);
+
+ return 0;
+}
+
+static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+
+ mtk_smi_clk_disable(&larb->smi);
+ pm_runtime_put_sync(larb->smi_common_dev);
+ return 0;
+}
+
+static const struct dev_pm_ops smi_larb_pm_ops = {
+ SET_RUNTIME_PM_OPS(mtk_smi_larb_suspend, mtk_smi_larb_resume, NULL)
+};
+
static struct platform_driver mtk_smi_larb_driver = {
.probe = mtk_smi_larb_probe,
.remove = mtk_smi_larb_remove,
.driver = {
.name = "mtk-smi-larb",
.of_match_table = mtk_smi_larb_of_ids,
+ .pm = &smi_larb_pm_ops,
}
};
@@ -488,12 +493,38 @@ static int mtk_smi_common_remove(struct platform_device *pdev)
return 0;
}
+static int __maybe_unused mtk_smi_common_resume(struct device *dev)
+{
+ struct mtk_smi *common = dev_get_drvdata(dev);
+ int ret;
+
+ ret = mtk_smi_clk_enable(common);
+ if (ret) {
+ dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
+ return ret;
+ }
+ return 0;
+}
+
+static int __maybe_unused mtk_smi_common_suspend(struct device *dev)
+{
+ struct mtk_smi *common = dev_get_drvdata(dev);
+
+ mtk_smi_clk_disable(common);
+ return 0;
+}
+
+static const struct dev_pm_ops smi_common_pm_ops = {
+ SET_RUNTIME_PM_OPS(mtk_smi_common_suspend, mtk_smi_common_resume, NULL)
+};
+
static struct platform_driver mtk_smi_common_driver = {
.probe = mtk_smi_common_probe,
.remove = mtk_smi_common_remove,
.driver = {
.name = "mtk-smi-common",
.of_match_table = mtk_smi_common_of_ids,
+ .pm = &smi_common_pm_ops,
}
};
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 11/18] iommu/mediatek: Add mmu1 support
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
Normally the M4U HW connect EMI with smi. the diagram is like below:
EMI
|
M4U
|
smi-common
|
-----------------
| | | | ...
larb0 larb1 larb2 larb3
Actually there are 2 mmu cells in the M4U HW, like this diagram:
EMI
---------
| |
mmu0 mmu1 <- M4U
| |
---------
|
smi-common
|
-----------------
| | | | ...
larb0 larb1 larb2 larb3
This patch add support for mmu1. In order to get better performance,
we could adjust some larbs go to mmu1 while the others still go to
mmu0. This is controlled by a SMI COMMON register SMI_BUS_SEL(0x220).
mt2712, mt8173 and mt8183 M4U HW all have 2 mmu cells. the default
value of that register is 0 which means all the larbs go to mmu0
defaultly.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 47 +++++++++++++++++++++++++++++------------------
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d91a554..1a87a1d 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -74,27 +74,32 @@
#define F_MISS_FIFO_ERR_INT_EN BIT(6)
#define F_INT_CLR_BIT BIT(12)
-#define REG_MMU_INT_MAIN_CONTROL 0x124
-#define F_INT_TRANSLATION_FAULT BIT(0)
-#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1)
-#define F_INT_INVALID_PA_FAULT BIT(2)
-#define F_INT_ENTRY_REPLACEMENT_FAULT BIT(3)
-#define F_INT_TLB_MISS_FAULT BIT(4)
-#define F_INT_MISS_TRANSACTION_FIFO_FAULT BIT(5)
-#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT BIT(6)
+#define REG_MMU_INT_MAIN_CONTROL 0x124 /* mmu0 | mmu1 */
+#define F_INT_TRANSLATION_FAULT (BIT(0) | BIT(7))
+#define F_INT_MAIN_MULTI_HIT_FAULT (BIT(1) | BIT(8))
+#define F_INT_INVALID_PA_FAULT (BIT(2) | BIT(9))
+#define F_INT_ENTRY_REPLACEMENT_FAULT (BIT(3) | BIT(10))
+#define F_INT_TLB_MISS_FAULT (BIT(4) | BIT(11))
+#define F_INT_MISS_TRANSACTION_FIFO_FAULT (BIT(5) | BIT(12))
+#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT (BIT(6) | BIT(13))
#define REG_MMU_CPE_DONE 0x12C
#define REG_MMU_FAULT_ST1 0x134
+#define F_REG_MMU0_FAULT_MASK GENMASK(6, 0)
+#define F_REG_MMU1_FAULT_MASK GENMASK(13, 7)
-#define REG_MMU_FAULT_VA 0x13c
+#define REG_MMU0_FAULT_VA 0x13c
#define F_MMU_FAULT_VA_WRITE_BIT BIT(1)
#define F_MMU_FAULT_VA_LAYER_BIT BIT(0)
-#define REG_MMU_INVLD_PA 0x140
-#define REG_MMU_INT_ID 0x150
-#define F_MMU0_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
-#define F_MMU0_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
+#define REG_MMU0_INVLD_PA 0x140
+#define REG_MMU1_FAULT_VA 0x144
+#define REG_MMU1_INVLD_PA 0x148
+#define REG_MMU0_INT_ID 0x150
+#define REG_MMU1_INT_ID 0x154
+#define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
+#define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
#define MTK_PROTECT_PA_ALIGN 128
@@ -213,13 +218,19 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
/* Read error info from registers */
int_state = readl_relaxed(data->base + REG_MMU_FAULT_ST1);
- fault_iova = readl_relaxed(data->base + REG_MMU_FAULT_VA);
+ if (int_state & F_REG_MMU0_FAULT_MASK) {
+ regval = readl_relaxed(data->base + REG_MMU0_INT_ID);
+ fault_iova = readl_relaxed(data->base + REG_MMU0_FAULT_VA);
+ fault_pa = readl_relaxed(data->base + REG_MMU0_INVLD_PA);
+ } else {
+ regval = readl_relaxed(data->base + REG_MMU1_INT_ID);
+ fault_iova = readl_relaxed(data->base + REG_MMU1_FAULT_VA);
+ fault_pa = readl_relaxed(data->base + REG_MMU1_INVLD_PA);
+ }
layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
- fault_pa = readl_relaxed(data->base + REG_MMU_INVLD_PA);
- regval = readl_relaxed(data->base + REG_MMU_INT_ID);
- fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
- fault_port = F_MMU0_INT_ID_PORT_ID(regval);
+ fault_larb = F_MMU_INT_ID_LARB_ID(regval);
+ fault_port = F_MMU_INT_ID_PORT_ID(regval);
if (data->plat_data->larbid_remap_enable)
fault_larb = data->plat_data->larbid_remapped[fault_larb];
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 07/18] iommu/mediatek: Add bclk can be supported optionally
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
In some SoCs, M4U doesn't have its "bclk", it will use the EMI
clock instead which has always been enabled when entering kernel.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 10 +++++++---
drivers/iommu/mtk_iommu.h | 3 +++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 8eb110e..eda062a 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -610,9 +610,11 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (data->irq < 0)
return data->irq;
- data->bclk = devm_clk_get(dev, "bclk");
- if (IS_ERR(data->bclk))
- return PTR_ERR(data->bclk);
+ if (data->plat_data->has_bclk) {
+ data->bclk = devm_clk_get(dev, "bclk");
+ if (IS_ERR(data->bclk))
+ return PTR_ERR(data->bclk);
+ }
larb_nr = of_count_phandle_with_args(dev->of_node,
"mediatek,larbs", NULL);
@@ -736,11 +738,13 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
.has_4gb_mode = true,
+ .has_bclk = true,
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.has_4gb_mode = true,
+ .has_bclk = true,
};
static const struct of_device_id mtk_iommu_of_ids[] = {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 5890e55..b8749ac 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -44,6 +44,9 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
bool has_4gb_mode;
+
+ /* HW will use the EMI clock if there isn't the "bclk". */
+ bool has_bclk;
};
struct mtk_iommu_domain;
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 05/18] iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr helpers
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
Add two helper functions: paddr_to_iopte and iopte_to_paddr.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm-v7s.c | 45 ++++++++++++++++++++++++++++----------
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 445c3bd..03bb7b9 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -173,18 +173,38 @@ struct arm_v7s_io_pgtable {
spinlock_t split_lock;
};
+static bool arm_v7s_pte_is_cont(arm_v7s_iopte pte, int lvl);
+
static dma_addr_t __arm_v7s_dma_addr(void *pages)
{
return (dma_addr_t)virt_to_phys(pages);
}
-static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl)
+static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
+ struct io_pgtable_cfg *cfg)
{
+ return paddr & ARM_V7S_LVL_MASK(lvl);
+}
+
+static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
+ struct io_pgtable_cfg *cfg)
+{
+ arm_v7s_iopte mask;
+
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
- pte &= ARM_V7S_TABLE_MASK;
+ mask = ARM_V7S_TABLE_MASK;
+ else if (arm_v7s_pte_is_cont(pte, lvl))
+ mask = ARM_V7S_LVL_MASK(lvl) * ARM_V7S_CONT_PAGES;
else
- pte &= ARM_V7S_LVL_MASK(lvl);
- return phys_to_virt(pte);
+ mask = ARM_V7S_LVL_MASK(lvl);
+
+ return pte & mask;
+}
+
+static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
+ struct arm_v7s_io_pgtable *data)
+{
+ return phys_to_virt(iopte_to_paddr(pte, lvl, &data->iop.cfg));
}
static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
@@ -396,7 +416,7 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
if (num_entries > 1)
pte = arm_v7s_pte_to_cont(pte, lvl);
- pte |= paddr & ARM_V7S_LVL_MASK(lvl);
+ pte |= paddr_to_iopte(paddr, lvl, cfg);
__arm_v7s_set_pte(ptep, pte, num_entries, cfg);
return 0;
@@ -462,7 +482,7 @@ static int __arm_v7s_map(struct arm_v7s_io_pgtable *data, unsigned long iova,
}
if (ARM_V7S_PTE_IS_TABLE(pte, lvl)) {
- cptep = iopte_deref(pte, lvl);
+ cptep = iopte_deref(pte, lvl, data);
} else if (pte) {
/* We require an unmap first */
WARN_ON(!selftest_running);
@@ -512,7 +532,8 @@ static void arm_v7s_free_pgtable(struct io_pgtable *iop)
arm_v7s_iopte pte = data->pgd[i];
if (ARM_V7S_PTE_IS_TABLE(pte, 1))
- __arm_v7s_free_table(iopte_deref(pte, 1), 2, data);
+ __arm_v7s_free_table(iopte_deref(pte, 1, data),
+ 2, data);
}
__arm_v7s_free_table(data->pgd, 1, data);
kmem_cache_destroy(data->l2_tables);
@@ -582,7 +603,7 @@ static size_t arm_v7s_split_blk_unmap(struct arm_v7s_io_pgtable *data,
if (!ARM_V7S_PTE_IS_TABLE(pte, 1))
return 0;
- tablep = iopte_deref(pte, 1);
+ tablep = iopte_deref(pte, 1, data);
return __arm_v7s_unmap(data, iova, size, 2, tablep);
}
@@ -641,7 +662,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
io_pgtable_tlb_add_flush(iop, iova, blk_size,
ARM_V7S_BLOCK_SIZE(lvl + 1), false);
io_pgtable_tlb_sync(iop);
- ptep = iopte_deref(pte[i], lvl);
+ ptep = iopte_deref(pte[i], lvl, data);
__arm_v7s_free_table(ptep, lvl + 1, data);
} else if (iop->cfg.quirks & IO_PGTABLE_QUIRK_NON_STRICT) {
/*
@@ -666,7 +687,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
}
/* Keep on walkin' */
- ptep = iopte_deref(pte[0], lvl);
+ ptep = iopte_deref(pte[0], lvl, data);
return __arm_v7s_unmap(data, iova, size, lvl + 1, ptep);
}
@@ -692,7 +713,7 @@ static phys_addr_t arm_v7s_iova_to_phys(struct io_pgtable_ops *ops,
do {
ptep += ARM_V7S_LVL_IDX(iova, ++lvl);
pte = READ_ONCE(*ptep);
- ptep = iopte_deref(pte, lvl);
+ ptep = iopte_deref(pte, lvl, data);
} while (ARM_V7S_PTE_IS_TABLE(pte, lvl));
if (!ARM_V7S_PTE_IS_VALID(pte))
@@ -701,7 +722,7 @@ static phys_addr_t arm_v7s_iova_to_phys(struct io_pgtable_ops *ops,
mask = ARM_V7S_LVL_MASK(lvl);
if (arm_v7s_pte_is_cont(pte, lvl))
mask *= ARM_V7S_CONT_PAGES;
- return (pte & mask) | (iova & ~mask);
+ return iopte_to_paddr(pte, lvl, &data->iop.cfg) | (iova & ~mask);
}
static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 04/18] memory: mtk-smi: Use a struct for the platform data for smi-common
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
Use a struct as the platform special data instead of the enumeration.
Also there is a minor change that moving the position of
"enum mtk_smi_gen" definition, this is because we expect define
"struct mtk_smi_common_plat" before it is referred.
This is a preparing patch for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/memory/mtk-smi.c | 35 ++++++++++++++++++++++++-----------
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 3b9ad0e..a5ddd42 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -49,6 +49,15 @@
#define SMI_LARB_NONSEC_CON(id) (0x380 + ((id) * 4))
#define F_MMU_EN BIT(0)
+enum mtk_smi_gen {
+ MTK_SMI_GEN1,
+ MTK_SMI_GEN2
+};
+
+struct mtk_smi_common_plat {
+ enum mtk_smi_gen gen;
+};
+
struct mtk_smi_larb_gen {
bool need_larbid;
int port_in_larb[MTK_LARB_NR_MAX + 1];
@@ -61,6 +70,8 @@ struct mtk_smi {
struct clk *clk_apb, *clk_smi;
struct clk *clk_async; /*only needed by mt2701*/
void __iomem *smi_ao_base;
+
+ const struct mtk_smi_common_plat *plat;
};
struct mtk_smi_larb { /* larb: local arbiter */
@@ -72,11 +83,6 @@ struct mtk_smi_larb { /* larb: local arbiter */
u32 *mmu;
};
-enum mtk_smi_gen {
- MTK_SMI_GEN1,
- MTK_SMI_GEN2
-};
-
static int mtk_smi_enable(const struct mtk_smi *smi)
{
int ret;
@@ -351,18 +357,26 @@ static int mtk_smi_larb_remove(struct platform_device *pdev)
}
};
+static const struct mtk_smi_common_plat mtk_smi_common_gen1 = {
+ .gen = MTK_SMI_GEN1,
+};
+
+static const struct mtk_smi_common_plat mtk_smi_common_gen2 = {
+ .gen = MTK_SMI_GEN2,
+};
+
static const struct of_device_id mtk_smi_common_of_ids[] = {
{
.compatible = "mediatek,mt8173-smi-common",
- .data = (void *)MTK_SMI_GEN2
+ .data = &mtk_smi_common_gen2,
},
{
.compatible = "mediatek,mt2701-smi-common",
- .data = (void *)MTK_SMI_GEN1
+ .data = &mtk_smi_common_gen1,
},
{
.compatible = "mediatek,mt2712-smi-common",
- .data = (void *)MTK_SMI_GEN2
+ .data = &mtk_smi_common_gen2,
},
{}
};
@@ -372,13 +386,13 @@ static int mtk_smi_common_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct mtk_smi *common;
struct resource *res;
- enum mtk_smi_gen smi_gen;
int ret;
common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
if (!common)
return -ENOMEM;
common->dev = dev;
+ common->plat = of_device_get_match_data(dev);
common->clk_apb = devm_clk_get(dev, "apb");
if (IS_ERR(common->clk_apb))
@@ -394,8 +408,7 @@ static int mtk_smi_common_probe(struct platform_device *pdev)
* clock into emi clock domain, but for mtk smi gen2, there's no smi ao
* base.
*/
- smi_gen = (enum mtk_smi_gen)of_device_get_match_data(dev);
- if (smi_gen == MTK_SMI_GEN1) {
+ if (common->plat->gen == MTK_SMI_GEN1) {
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
common->smi_ao_base = devm_ioremap_resource(dev, res);
if (IS_ERR(common->smi_ao_base))
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 03/18] memory: mtk-smi: Use a general config_port interface
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
The config_port of mt2712 and mt8183 are the same. Use a general
config_port interface instead.
In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which
are not the normal larb, their register space are different from the
normal one. thus, we can not call the general config_port. In mt8183,
IPU0/1 and CCU connect with smi-common directly, they also are not
the normal larb. Hence, we add a "larb_special_mask" for these special
larbs.
This is also a preparing patch for adding mt8183 SMI support.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/memory/mtk-smi.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 8f2d152..3b9ad0e 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -53,6 +53,7 @@ struct mtk_smi_larb_gen {
bool need_larbid;
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
+ unsigned int larb_special_mask; /* The special larbs mask. */
};
struct mtk_smi {
@@ -176,17 +177,13 @@ void mtk_smi_larb_put(struct device *larbdev)
return -ENODEV;
}
-static void mtk_smi_larb_config_port_mt2712(struct device *dev)
+static void mtk_smi_larb_config_port_gen2_general(struct device *dev)
{
struct mtk_smi_larb *larb = dev_get_drvdata(dev);
u32 reg;
int i;
- /*
- * larb 8/9 is the bdpsys larb, the iommu_en is enabled defaultly.
- * Don't need to set it again.
- */
- if (larb->larbid == 8 || larb->larbid == 9)
+ if (BIT(larb->larbid) & larb->larb_gen->larb_special_mask)
return;
for_each_set_bit(i, (unsigned long *)larb->mmu, 32) {
@@ -261,7 +258,8 @@ static void mtk_smi_larb_config_port_gen1(struct device *dev)
static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {
.need_larbid = true,
- .config_port = mtk_smi_larb_config_port_mt2712,
+ .config_port = mtk_smi_larb_config_port_gen2_general,
+ .larb_special_mask = BIT(8) | BIT(9), /* bdpsys */
};
static const struct of_device_id mtk_smi_larb_of_ids[] = {
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 02/18] iommu/mediatek: Use a struct as the platform data
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
Use a struct as the platform special data instead of the enumeration.
This is a prepare patch for adding mt8183 iommu support.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 24 ++++++++++++++++--------
drivers/iommu/mtk_iommu.h | 6 +++++-
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 44bd5b9..9a2225b 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -54,7 +54,7 @@
#define REG_MMU_CTRL_REG 0x110
#define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4)
#define F_MMU_TF_PROTECT_SEL_SHIFT(data) \
- ((data)->m4u_plat == M4U_MT2712 ? 4 : 5)
+ ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5)
/* It's named by F_MMU_TF_PROT_SEL in mt2712. */
#define F_MMU_TF_PROTECT_SEL(prot, data) \
(((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
@@ -517,7 +517,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
regval = F_MMU_TF_PROTECT_SEL(2, data);
- if (data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->m4u_plat == M4U_MT8173)
regval |= F_MMU_PREFETCH_RT_REPLACE_MOD;
writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
@@ -538,14 +538,14 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
- if (data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->m4u_plat == M4U_MT8173)
regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
else
regval = lower_32_bits(data->protect_base) |
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->m4u_plat != M4U_MT8173) {
+ if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
@@ -556,7 +556,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
/* It's MISC control register whose default value is ok except mt8173.*/
- if (data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->m4u_plat == M4U_MT8173)
writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
@@ -589,7 +589,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
data->dev = dev;
- data->m4u_plat = (enum mtk_iommu_plat)of_device_get_match_data(dev);
+ data->plat_data = of_device_get_match_data(dev);
/* Protect memory. HW will access here while translation fault.*/
protect = devm_kzalloc(dev, MTK_PROTECT_PA_ALIGN * 2, GFP_KERNEL);
@@ -733,9 +733,17 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
};
+static const struct mtk_iommu_plat_data mt2712_data = {
+ .m4u_plat = M4U_MT2712,
+};
+
+static const struct mtk_iommu_plat_data mt8173_data = {
+ .m4u_plat = M4U_MT8173,
+};
+
static const struct of_device_id mtk_iommu_of_ids[] = {
- { .compatible = "mediatek,mt2712-m4u", .data = (void *)M4U_MT2712},
- { .compatible = "mediatek,mt8173-m4u", .data = (void *)M4U_MT8173},
+ { .compatible = "mediatek,mt2712-m4u", .data = &mt2712_data},
+ { .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
{}
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 778498b..333a0ef 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -41,6 +41,10 @@ enum mtk_iommu_plat {
M4U_MT8173,
};
+struct mtk_iommu_plat_data {
+ enum mtk_iommu_plat m4u_plat;
+};
+
struct mtk_iommu_domain;
struct mtk_iommu_data {
@@ -57,7 +61,7 @@ struct mtk_iommu_data {
bool tlb_flush_active;
struct iommu_device iommu;
- enum mtk_iommu_plat m4u_plat;
+ const struct mtk_iommu_plat_data *plat_data;
struct list_head list;
};
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 01/18] dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
This patch adds decriptions for mt8183 IOMMU and SMI.
mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
uses ARM Short-Descriptor translation table format.
The mt8183 M4U-SMI HW diagram is as below:
EMI
|
M4U
|
----------
| |
gals0-rx gals1-rx
| |
| |
gals0-tx gals1-tx
| |
------------
SMI Common
------------
|
+-----+-----+--------+-----+-----+-------+-------+
| | | | | | | |
| | gals-rx gals-rx | gals-rx gals-rx gals-rx
| | | | | | | |
| | | | | | | |
| | gals-tx gals-tx | gals-tx gals-tx gals-tx
| | | | | | | |
larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
disp vdec img cam venc img cam
All the connections are HW fixed, SW can NOT adjust it.
Compared with mt8173, we add a GALS(Global Async Local Sync) module
between SMI-common and M4U, and additional GALS between larb2/3/5/6
and SMI-common. GALS can help synchronize for the modules in different
clock frequency, it can be seen as a "asynchronous fifo".
GALS can only help transfer the command/data while it doesn't have
the configuring register, thus it has the special "smi" clock and it
doesn't have the "apb" clock. From the diagram above, we add "gals0"
and "gals1" clocks for smi-common and add a "gals" clock for smi-larb.
From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera
Control Unit) is connected with smi-common directly, we can take them
as "larb2", "larb3" and "larb7", and their register spaces are
different with the normal larb.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/iommu/mediatek,iommu.txt | 15 ++-
.../memory-controllers/mediatek,smi-common.txt | 11 +-
.../memory-controllers/mediatek,smi-larb.txt | 3 +
include/dt-bindings/memory/mt8183-larb-port.h | 130 +++++++++++++++++++++
4 files changed, 153 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/memory/mt8183-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
index 6922db5..6e758996 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -36,6 +36,10 @@ each local arbiter.
like display, video decode, and camera. And there are different ports
in each larb. Take a example, There are many ports like MC, PP, VLD in the
video decode local arbiter, all these ports are according to the video HW.
+ In some SoCs, there may be a GALS(Global Async Local Sync) module between
+smi-common and m4u, and additional GALS module between smi-larb and
+smi-common. GALS can been seen as a "asynchronous fifo" which could help
+synchronize for the modules in different clock frequency.
Required properties:
- compatible : must be one of the following string:
@@ -44,18 +48,23 @@ Required properties:
"mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses
generation one m4u HW.
"mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
+ "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW.
- reg : m4u register base and size.
- interrupts : the interrupt of m4u.
- clocks : must contain one entry for each clock-names.
-- clock-names : must be "bclk", It is the block clock of m4u.
+- clock-names : Only 1 optional clock:
+ - "bclk": the block clock of m4u.
+ Note that m4u use the EMI clock which always has been enabled before kernel
+ if there is no this "bclk".
- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
according to the local arbiter index, like larb0, larb1, larb2...
- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
Specifies the mtk_m4u_id as defined in
dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623
- dt-binding/memory/mt2712-larb-port.h for mt2712, and
- dt-binding/memory/mt8173-larb-port.h for mt8173.
+ dt-binding/memory/mt2712-larb-port.h for mt2712,
+ dt-binding/memory/mt8173-larb-port.h for mt8173, and
+ dt-binding/memory/mt8183-larb-port.h for mt8183.
Example:
iommu: iommu@10205000 {
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
index e937ddd..8d3240a 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
@@ -2,9 +2,10 @@ SMI (Smart Multimedia Interface) Common
The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
-Mediatek SMI have two generations of HW architecture, mt2712 and mt8173 use
-the second generation of SMI HW while mt2701 uses the first generation HW of
-SMI.
+Mediatek SMI have two generations of HW architecture, here is the list
+which generation the Socs use:
+generation 1: mt2701 and mt7623.
+generation 2: mt2712, mt8173 and mt8183.
There's slight differences between the two SMI, for generation 2, the
register which control the iommu port is at each larb's register base. But
@@ -19,6 +20,7 @@ Required properties:
"mediatek,mt2712-smi-common"
"mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
"mediatek,mt8173-smi-common"
+ "mediatek,mt8183-smi-common"
- reg : the register and size of the SMI block.
- power-domains : a phandle to the power domain of this local arbiter.
- clocks : Must contain an entry for each entry in clock-names.
@@ -30,6 +32,9 @@ Required properties:
They may be the same if both source clocks are the same.
- "async" : asynchronous clock, it help transform the smi clock into the emi
clock domain, this clock is only needed by generation 1 smi HW.
+ and these 2 option clocks for generation 2 smi HW:
+ - "gals0": the path0 clock of GALS(Global Async Local Sync).
+ - "gals1": the path1 clock of GALS(Global Async Local Sync).
Example:
smi_common: smi@14022000 {
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
index 94eddca..69266c9 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
@@ -8,6 +8,7 @@ Required properties:
"mediatek,mt2712-smi-larb"
"mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb"
"mediatek,mt8173-smi-larb"
+ "mediatek,mt8183-smi-larb"
- reg : the register and size of this local arbiter.
- mediatek,smi : a phandle to the smi_common node.
- power-domains : a phandle to the power domain of this local arbiter.
@@ -16,6 +17,8 @@ Required properties:
- "apb" : Advanced Peripheral Bus clock, It's the clock for setting
the register.
- "smi" : It's the clock for transfer data and command.
+ and this optional clock name:
+ - "gals": the clock for gals(Global Async Local Sync).
Required property for mt2701, mt2712 and mt7623:
- mediatek,larb-id :the hardware id of this larb.
diff --git a/include/dt-bindings/memory/mt8183-larb-port.h b/include/dt-bindings/memory/mt8183-larb-port.h
new file mode 100644
index 0000000..2c579f3
--- /dev/null
+++ b/include/dt-bindings/memory/mt8183-larb-port.h
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Yong Wu <yong.wu@mediatek.com>
+ */
+#ifndef __DTS_IOMMU_PORT_MT8183_H
+#define __DTS_IOMMU_PORT_MT8183_H
+
+#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+
+#define M4U_LARB0_ID 0
+#define M4U_LARB1_ID 1
+#define M4U_LARB2_ID 2
+#define M4U_LARB3_ID 3
+#define M4U_LARB4_ID 4
+#define M4U_LARB5_ID 5
+#define M4U_LARB6_ID 6
+#define M4U_LARB7_ID 7
+
+/* larb0 */
+#define M4U_PORT_DISP_OVL0 MTK_M4U_ID(M4U_LARB0_ID, 0)
+#define M4U_PORT_DISP_2L_OVL0_LARB0 MTK_M4U_ID(M4U_LARB0_ID, 1)
+#define M4U_PORT_DISP_2L_OVL1_LARB0 MTK_M4U_ID(M4U_LARB0_ID, 2)
+#define M4U_PORT_DISP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 3)
+#define M4U_PORT_DISP_RDMA1 MTK_M4U_ID(M4U_LARB0_ID, 4)
+#define M4U_PORT_DISP_WDMA0 MTK_M4U_ID(M4U_LARB0_ID, 5)
+#define M4U_PORT_MDP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 6)
+#define M4U_PORT_MDP_WROT0 MTK_M4U_ID(M4U_LARB0_ID, 7)
+#define M4U_PORT_MDP_WDMA0 MTK_M4U_ID(M4U_LARB0_ID, 8)
+#define M4U_PORT_DISP_FAKE0 MTK_M4U_ID(M4U_LARB0_ID, 9)
+
+/* larb1 */
+#define M4U_PORT_HW_VDEC_MC_EXT MTK_M4U_ID(M4U_LARB1_ID, 0)
+#define M4U_PORT_HW_VDEC_PP_EXT MTK_M4U_ID(M4U_LARB1_ID, 1)
+#define M4U_PORT_HW_VDEC_VLD_EXT MTK_M4U_ID(M4U_LARB1_ID, 2)
+#define M4U_PORT_HW_VDEC_AVC_MV_EXT MTK_M4U_ID(M4U_LARB1_ID, 3)
+#define M4U_PORT_HW_VDEC_PRED_RD_EXT MTK_M4U_ID(M4U_LARB1_ID, 4)
+#define M4U_PORT_HW_VDEC_PRED_WR_EXT MTK_M4U_ID(M4U_LARB1_ID, 5)
+#define M4U_PORT_HW_VDEC_PPWRAP_EXT MTK_M4U_ID(M4U_LARB1_ID, 6)
+
+/* larb2 VPU0 */
+#define M4U_PORT_IMG_IPUO MTK_M4U_ID(M4U_LARB2_ID, 0)
+#define M4U_PORT_IMG_IPU3O MTK_M4U_ID(M4U_LARB2_ID, 1)
+#define M4U_PORT_IMG_IPUI MTK_M4U_ID(M4U_LARB2_ID, 2)
+
+/* larb3 VPU1 */
+#define M4U_PORT_CAM_IPUO MTK_M4U_ID(M4U_LARB3_ID, 0)
+#define M4U_PORT_CAM_IPU2O MTK_M4U_ID(M4U_LARB3_ID, 1)
+#define M4U_PORT_CAM_IPU3O MTK_M4U_ID(M4U_LARB3_ID, 2)
+#define M4U_PORT_CAM_IPUI MTK_M4U_ID(M4U_LARB3_ID, 3)
+#define M4U_PORT_CAM_IPU2I MTK_M4U_ID(M4U_LARB3_ID, 4)
+
+/* larb4 */
+#define M4U_PORT_VENC_RCPU MTK_M4U_ID(M4U_LARB4_ID, 0)
+#define M4U_PORT_VENC_REC MTK_M4U_ID(M4U_LARB4_ID, 1)
+#define M4U_PORT_VENC_BSDMA MTK_M4U_ID(M4U_LARB4_ID, 2)
+#define M4U_PORT_VENC_SV_COMV MTK_M4U_ID(M4U_LARB4_ID, 3)
+#define M4U_PORT_VENC_RD_COMV MTK_M4U_ID(M4U_LARB4_ID, 4)
+#define M4U_PORT_JPGENC_RDMA MTK_M4U_ID(M4U_LARB4_ID, 5)
+#define M4U_PORT_JPGENC_BSDMA MTK_M4U_ID(M4U_LARB4_ID, 6)
+#define M4U_PORT_VENC_CUR_LUMA MTK_M4U_ID(M4U_LARB4_ID, 7)
+#define M4U_PORT_VENC_CUR_CHROMA MTK_M4U_ID(M4U_LARB4_ID, 8)
+#define M4U_PORT_VENC_REF_LUMA MTK_M4U_ID(M4U_LARB4_ID, 9)
+#define M4U_PORT_VENC_REF_CHROMA MTK_M4U_ID(M4U_LARB4_ID, 10)
+
+/* larb5 */
+#define M4U_PORT_CAM_IMGI MTK_M4U_ID(M4U_LARB5_ID, 0)
+#define M4U_PORT_CAM_IMG2O MTK_M4U_ID(M4U_LARB5_ID, 1)
+#define M4U_PORT_CAM_IMG3O MTK_M4U_ID(M4U_LARB5_ID, 2)
+#define M4U_PORT_CAM_VIPI MTK_M4U_ID(M4U_LARB5_ID, 3)
+#define M4U_PORT_CAM_LCEI MTK_M4U_ID(M4U_LARB5_ID, 4)
+#define M4U_PORT_CAM_SMXI MTK_M4U_ID(M4U_LARB5_ID, 5)
+#define M4U_PORT_CAM_SMXO MTK_M4U_ID(M4U_LARB5_ID, 6)
+#define M4U_PORT_CAM_WPE0_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 7)
+#define M4U_PORT_CAM_WPE0_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 8)
+#define M4U_PORT_CAM_WPE0_WDMA MTK_M4U_ID(M4U_LARB5_ID, 9)
+#define M4U_PORT_CAM_FDVT_RP MTK_M4U_ID(M4U_LARB5_ID, 10)
+#define M4U_PORT_CAM_FDVT_WR MTK_M4U_ID(M4U_LARB5_ID, 11)
+#define M4U_PORT_CAM_FDVT_RB MTK_M4U_ID(M4U_LARB5_ID, 12)
+#define M4U_PORT_CAM_WPE1_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 13)
+#define M4U_PORT_CAM_WPE1_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 14)
+#define M4U_PORT_CAM_WPE1_WDMA MTK_M4U_ID(M4U_LARB5_ID, 15)
+#define M4U_PORT_CAM_DPE_RDMA MTK_M4U_ID(M4U_LARB5_ID, 16)
+#define M4U_PORT_CAM_DPE_WDMA MTK_M4U_ID(M4U_LARB5_ID, 17)
+#define M4U_PORT_CAM_MFB_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 18)
+#define M4U_PORT_CAM_MFB_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 19)
+#define M4U_PORT_CAM_MFB_WDMA MTK_M4U_ID(M4U_LARB5_ID, 20)
+#define M4U_PORT_CAM_RSC_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 21)
+#define M4U_PORT_CAM_RSC_WDMA MTK_M4U_ID(M4U_LARB5_ID, 22)
+#define M4U_PORT_CAM_OWE_RDMA MTK_M4U_ID(M4U_LARB5_ID, 23)
+#define M4U_PORT_CAM_OWE_WDMA MTK_M4U_ID(M4U_LARB5_ID, 24)
+
+/* larb6 */
+#define M4U_PORT_CAM_IMGO MTK_M4U_ID(M4U_LARB6_ID, 0)
+#define M4U_PORT_CAM_RRZO MTK_M4U_ID(M4U_LARB6_ID, 1)
+#define M4U_PORT_CAM_AAO MTK_M4U_ID(M4U_LARB6_ID, 2)
+#define M4U_PORT_CAM_AFO MTK_M4U_ID(M4U_LARB6_ID, 3)
+#define M4U_PORT_CAM_LSCI0 MTK_M4U_ID(M4U_LARB6_ID, 4)
+#define M4U_PORT_CAM_LSCI1 MTK_M4U_ID(M4U_LARB6_ID, 5)
+#define M4U_PORT_CAM_PDO MTK_M4U_ID(M4U_LARB6_ID, 6)
+#define M4U_PORT_CAM_BPCI MTK_M4U_ID(M4U_LARB6_ID, 7)
+#define M4U_PORT_CAM_LCSO MTK_M4U_ID(M4U_LARB6_ID, 8)
+#define M4U_PORT_CAM_CAM_RSSO_A MTK_M4U_ID(M4U_LARB6_ID, 9)
+#define M4U_PORT_CAM_UFEO MTK_M4U_ID(M4U_LARB6_ID, 10)
+#define M4U_PORT_CAM_SOCO MTK_M4U_ID(M4U_LARB6_ID, 11)
+#define M4U_PORT_CAM_SOC1 MTK_M4U_ID(M4U_LARB6_ID, 12)
+#define M4U_PORT_CAM_SOC2 MTK_M4U_ID(M4U_LARB6_ID, 13)
+#define M4U_PORT_CAM_CCUI MTK_M4U_ID(M4U_LARB6_ID, 14)
+#define M4U_PORT_CAM_CCUO MTK_M4U_ID(M4U_LARB6_ID, 15)
+#define M4U_PORT_CAM_RAWI_A MTK_M4U_ID(M4U_LARB6_ID, 16)
+#define M4U_PORT_CAM_CCUG MTK_M4U_ID(M4U_LARB6_ID, 17)
+#define M4U_PORT_CAM_PSO MTK_M4U_ID(M4U_LARB6_ID, 18)
+#define M4U_PORT_CAM_AFO_1 MTK_M4U_ID(M4U_LARB6_ID, 19)
+#define M4U_PORT_CAM_LSCI_2 MTK_M4U_ID(M4U_LARB6_ID, 20)
+#define M4U_PORT_CAM_PDI MTK_M4U_ID(M4U_LARB6_ID, 21)
+#define M4U_PORT_CAM_FLKO MTK_M4U_ID(M4U_LARB6_ID, 22)
+#define M4U_PORT_CAM_LMVO MTK_M4U_ID(M4U_LARB6_ID, 23)
+#define M4U_PORT_CAM_UFGO MTK_M4U_ID(M4U_LARB6_ID, 24)
+#define M4U_PORT_CAM_SPARE MTK_M4U_ID(M4U_LARB6_ID, 25)
+#define M4U_PORT_CAM_SPARE_2 MTK_M4U_ID(M4U_LARB6_ID, 26)
+#define M4U_PORT_CAM_SPARE_3 MTK_M4U_ID(M4U_LARB6_ID, 27)
+#define M4U_PORT_CAM_SPARE_4 MTK_M4U_ID(M4U_LARB6_ID, 28)
+#define M4U_PORT_CAM_SPARE_5 MTK_M4U_ID(M4U_LARB6_ID, 29)
+#define M4U_PORT_CAM_SPARE_6 MTK_M4U_ID(M4U_LARB6_ID, 30)
+
+/* CCU */
+#define M4U_PORT_CCU0 MTK_M4U_ID(M4U_LARB7_ID, 0)
+#define M4U_PORT_CCU1 MTK_M4U_ID(M4U_LARB7_ID, 1)
+
+#endif
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 00/18] MT8183 IOMMU SUPPORT
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
This patchset mainly adds support for mt8183 IOMMU and SMI.
mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
uses ARM Short-Descriptor translation table format.
The mt8183 M4U-SMI HW diagram is as below:
EMI
|
M4U
|
----------
| |
gals0-rx gals1-rx
| |
| |
gals0-tx gals1-tx
| |
------------
SMI Common
------------
|
+-----+-----+--------+-----+-----+-------+-------+
| | | | | | | |
| | gals-rx gals-rx | gals-rx gals-rx gals-rx
| | | | | | | |
| | | | | | | |
| | gals-tx gals-tx | gals-tx gals-tx gals-tx
| | | | | | | |
larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
disp vdec img cam venc img cam
All the connections are HW fixed, SW can NOT adjust it.
Compared with mt8173, we add a GALS(Global Async Local Sync) module
between SMI-common and M4U, and additional GALS between larb2/3/5/6
and SMI-common. GALS can help synchronize for the modules in different
clock frequency, it can be seen as a "asynchronous fifo".
GALS can only help transfer the command/data while it doesn't have
the configuring register, thus it has the special "smi" clock and it
doesn't have the "apb" clock. From the diagram above, we add "gals0"
and "gals1" clocks for smi-common and add a "gals" clock for smi-larb.
From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera
Control Unit) is connected with smi-common directly, we can take them
as "larb2", "larb3" and "larb7", and their register spaces are
different with the normal larb.
This is the general purpose of each patch in this patchset:
the patch 1..10 add the iommu/smi support for mt8183;
the patch 11/12/13 add mmu1 support;
the last patches contain some minor changes:
-patch 14 fix a issue.
-patch 15 improve the code flow(add shutdown).
-patch 16 cleanup some smi codes(delete need_larbid).
-patch 17 switch to SPDX license.
-patch 18 Constify iommu_ops from Arvind.
this patchset don't contain the dtsi part since it need depend on the
ccf and power-domain nodes which has not been accepted.
Change notes:
v4: 1) Add 3 preparing patches. Seperate some minor meaningful code into
a new patch according to Matthias's suggestion.
memory: mtk-smi: Add gals support
iommu/mediatek: Add larb-id remapped support
iommu/mediatek: Add bclk can be supported optionally
2) rebase on "iommu/mediatek: Make it explicitly non-modular"
which was applied.
https://lore.kernel.org/patchwork/patch/1020125/
3) add some comment about "mediatek,larb-id" in the commit message of
the patch "mtk-smi: Get rid of need_larbid".
4) Fix bus_sel value.
v3: https://lists.linuxfoundation.org/pipermail/iommu/2018-November/031121.html
1) rebase on v4.20-rc1.
2) In the dt-binding, add a minor string "mt7623" which also use gen1
since Matthias added it in v4.20.
3) About v7s:
a) for paddr_to_pte, change the param from "arm_v7s_io_pgtable" to
"arm_pgtable_cfg", according to Robin suggestion.
b) Don't use CONFIG_PHYS_ADDR_T_64BIT.
c) add a little comment(pgtable address still don't over 4GB) in the
commit message of the patch "Extend MediaTek 4GB Mode".
4) add "iommu/mediatek: Constify iommu_ops" into this patchset. this may
be helpful for review and merge.
https://lists.linuxfoundation.org/pipermail/iommu/2018-October/030637.html
v2: https://lists.linuxfoundation.org/pipermail/iommu/2018-September/030164.html
1) Fix typo in the commit message of dt-binding.
2) Change larb2/larb3 to the special larbs.
3) Refactor the larb-id remapped array(larbid_remapped), then we
don't need add the new function(mtk_iommu_get_larbid).
4) Add a new patch for v7s two helpers(paddr_to_iopte and
iopte_to_paddr).
5) Change some comment for MTK 4GB mode.
v1: base on v4.19-rc1.
http://lists.infradead.org/pipermail/linux-mediatek/2018-September/014881.html
Arvind Yadav (1):
iommu/mediatek: Constify iommu_ops
Yong Wu (17):
dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
iommu/mediatek: Use a struct as the platform data
memory: mtk-smi: Use a general config_port interface
memory: mtk-smi: Use a struct for the platform data for smi-common
iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr
helpers
iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
iommu/mediatek: Add bclk can be supported optionally
iommu/mediatek: Add larb-id remapped support
memory: mtk-smi: Add gals support
iommu/mediatek: Add mt8183 IOMMU support
iommu/mediatek: Add mmu1 support
memory: mtk-smi: Invoke pm runtime_callback to enable clocks
memory: mtk-smi: Add bus_sel for mt8183
iommu/mediatek: Fix VLD_PA_RANGE register backup when suspend
iommu/mediatek: Add shutdown callback
memory: mtk-smi: Get rid of need_larbid
iommu/mediatek: Switch to SPDX license identifier
.../devicetree/bindings/iommu/mediatek,iommu.txt | 15 +-
.../memory-controllers/mediatek,smi-common.txt | 11 +-
.../memory-controllers/mediatek,smi-larb.txt | 3 +
drivers/iommu/io-pgtable-arm-v7s.c | 72 ++++--
drivers/iommu/io-pgtable.h | 7 +-
drivers/iommu/mtk_iommu.c | 141 +++++++----
drivers/iommu/mtk_iommu.h | 26 +-
drivers/iommu/mtk_iommu_v1.c | 14 +-
drivers/memory/mtk-smi.c | 269 ++++++++++++++-------
include/dt-bindings/memory/mt2701-larb-port.h | 10 +-
include/dt-bindings/memory/mt8173-larb-port.h | 10 +-
include/dt-bindings/memory/mt8183-larb-port.h | 130 ++++++++++
include/soc/mediatek/smi.h | 10 +-
13 files changed, 501 insertions(+), 217 deletions(-)
create mode 100644 include/dt-bindings/memory/mt8183-larb-port.h
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.20 (#1)
From: Gregory CLEMENT @ 2018-12-08 8:39 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, arm
Cc: Andrew Lunn, Jason Cooper, linux-arm-kernel,
Sebastian Hesselbarth
Hi,
Here is the first pull request for fixes for mvebu for v4.20.
Gregory
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.20-1
for you to fetch changes up to dae522045094ebfa9a10cf7951a8f79b02da8e15:
Revert "arm64: dts: marvell: add CPU Idle power state support on Armada 7K/8K" (2018-12-05 09:28:17 +0100)
----------------------------------------------------------------
mvebu fixes for 4.20
Adding CPU Idle state in the device tree for Armada 8040 seems to
breaks boot on some board, so let's revert it waiting for a better
solution.
----------------------------------------------------------------
Baruch Siach (1):
Revert "arm64: dts: marvell: add CPU Idle power state support on Armada 7K/8K"
arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi | 4 ----
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 27 ----------------------
2 files changed, 31 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] kbuild: move .SECONDARY special target to Kbuild.include
From: Masahiro Yamada @ 2018-12-08 6:54 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Jason, Michal Marek, Herbert Xu, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, Russell King, linux-crypto,
David S. Miller, linux-arm-kernel
In-Reply-To: <1543624035-4479-1-git-send-email-yamada.masahiro@socionext.com>
On Sat, Dec 1, 2018 at 9:29 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> In commit 54a702f70589 ("kbuild: mark $(targets) as .SECONDARY and
> remove .PRECIOUS markers"), I missed one important feature of the
> .SECONDARY target:
>
> .SECONDARY with no prerequisites causes all targets to be treated
> as secondary.
>
> Kbuild's policy is, "Do not delete any intermediate files."
> So, just move it to scripts/Kbuild.include, with no prerequisites.
>
> Note:
> If an intermediate file is generated by $(call if_changed,...), you
> still need to add it to "targets" so its .*.cmd file is included.
>
> The arm/arm64 crypto files are generated by $(call cmd,shipped),
> so they do not need to be added to "targets", but need to be added
> to "clean-files" so "make clean" can properly clean them away.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to linux-kbuild.
> arch/arm/crypto/Makefile | 2 +-
> arch/arm64/crypto/Makefile | 2 +-
> scripts/Kbuild.include | 3 +++
> scripts/Makefile.build | 4 ----
> 4 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
> index bd5bcee..89f88ab 100644
> --- a/arch/arm/crypto/Makefile
> +++ b/arch/arm/crypto/Makefile
> @@ -65,4 +65,4 @@ $(src)/sha512-core.S_shipped: $(src)/sha512-armv4.pl
> $(call cmd,perl)
> endif
>
> -targets += sha256-core.S sha512-core.S
> +clean-files += sha256-core.S sha512-core.S
> diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
> index f476fed..860d931 100644
> --- a/arch/arm64/crypto/Makefile
> +++ b/arch/arm64/crypto/Makefile
> @@ -75,4 +75,4 @@ $(src)/sha512-core.S_shipped: $(src)/sha512-armv8.pl
> $(call cmd,perlasm)
> endif
>
> -targets += sha256-core.S sha512-core.S
> +clean-files += sha256-core.S sha512-core.S
> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> index bb01555..0454916 100644
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -393,3 +393,6 @@ endef
>
> # delete partially updated (i.e. corrupted) files on error
> .DELETE_ON_ERROR:
> +
> +# do not delete intermediate files automatically
> +.SECONDARY:
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index a8e7ba9..604096a 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -546,8 +546,4 @@ $(shell mkdir -p $(obj-dirs))
> endif
> endif
>
> -# Some files contained in $(targets) are intermediate artifacts.
> -# We never want them to be removed automatically.
> -.SECONDARY: $(targets)
> -
> .PHONY: $(PHONY)
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 01/10] mailbox: Support blocking transfers in atomic context
From: Jassi Brar @ 2018-12-08 6:09 UTC (permalink / raw)
To: Thierry Reding
Cc: Devicetree List, Greg KH, mliljeberg, Mikko Perttunen, talho,
linux-serial, jslaby, linux-tegra, ppessi, Jon Hunter,
linux-arm-kernel
In-Reply-To: <20181207113245.GA30719@ulmo>
On Fri, Dec 7, 2018 at 5:02 PM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Thu, Dec 06, 2018 at 11:56:25PM -0600, Jassi Brar wrote:
> > On Thu, Nov 29, 2018 at 9:23 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Wed, Nov 28, 2018 at 11:23:36PM -0600, Jassi Brar wrote:
> > > > On Wed, Nov 28, 2018 at 3:43 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> > > > >
> > > > >
> > > > > On 12/11/2018 15:18, Thierry Reding wrote:
> > > > > > From: Thierry Reding <treding@nvidia.com>
> > > > > >
> > > > > > The mailbox framework supports blocking transfers via completions for
> > > > > > clients that can sleep. In order to support blocking transfers in cases
> > > > > > where the transmission is not permitted to sleep, add a new ->flush()
> > > > > > callback that controller drivers can implement to busy loop until the
> > > > > > transmission has been completed. This will automatically be called when
> > > > > > available and interrupts are disabled for clients that request blocking
> > > > > > transfers.
> > > > > >
> > > > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > > > ---
> > > > > > drivers/mailbox/mailbox.c | 8 ++++++++
> > > > > > include/linux/mailbox_controller.h | 4 ++++
> > > > > > 2 files changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> > > > > > index 674b35f402f5..0eaf21259874 100644
> > > > > > --- a/drivers/mailbox/mailbox.c
> > > > > > +++ b/drivers/mailbox/mailbox.c
> > > > > > @@ -267,6 +267,14 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
> > > > > > unsigned long wait;
> > > > > > int ret;
> > > > > >
> > > > > > + if (irqs_disabled() && chan->mbox->ops->flush) {
> > > > > > + ret = chan->mbox->ops->flush(chan, chan->cl->tx_tout);
> > > > > > + if (ret < 0)
> > > > > > + tx_tick(chan, ret);
> > > > > > +
> > > > > > + return ret;
> > > > > > + }
> > > > >
> > > > > It seems to me that if mbox_send_message() is called from an atomic
> > > > > context AND tx_block is true, then if 'flush' is not populated this
> > > > > should be an error condition as we do not wish to call
> > > > > wait_for_completion from an atomic context.
> > > > >
> > > > > I understand that there is some debate about adding such flush support,
> > > > > but irrespective of the above change, it seems to me that if the
> > > > > mbox_send_message() can be called from an atomic context (which it
> > > > > appears to), then it should be detecting if someone is trying to do so
> > > > > with 'tx_block' set as this should be an error.
> > > > >
> > > > Layers within kernel space have to trust each other. A badly written
> > > > client can break the consumer in so many ways, we can not catch every
> > > > possibility.
> > > >
> > > > > Furthermore, if the underlying mailbox driver can support sending a
> > > > > message from an atomic context and busy wait until it is done, surely
> > > > > the mailbox framework should provide a means to support this?
> > > > >
> > > > Being able to put the message on bus in atomic context is a feature -
> > > > which we do support. But busy-waiting in a loop is not a feature, and
> > > > we don't want to encourage that.
> > >
> > > I agree that in generally busy-waiting is a bad idea and shouldn't be
> > > encouraged. However, I also think that an exception proves the rule. If
> > > you look at the console drivers in drivers/tty/serial, all of them will
> > > busy loop prior to or after sending a character. This is pretty much
> > > part of the API and as such busy-looping is very much a feature.
> > >
> > > The reason why this is done is because on one hand we have an atomic
> > > context and on the other hand we want to make sure that all characters
> > > actually make it to the console when we print them.
> > >
> > > As an example how this can break, I've taken your suggestion to
> > > implement a producer/consumer mode in the TCU driver where the console
> > > write function will just stash characters into a circular buffer and a
> > > work queue will then use mbox_send_message() to drain the circular
> > > buffer. While this does work on the surface, I was able to concern both
> > > of the issues that I was concerned about: 1) it is easy to overflow the
> > > circular buffer by just dumping enough data at once to the console and
> > > 2) when a crash happens, everything in the kernel stops, including the
> > > consumer workqueue that is supposed to drain the circular buffer and
> > > flush messages to the TCU. The result is that, in my particular case,
> > > the boot log will just stop at a random place in the middle of messages
> > > from much earlier in the boot because the TCU hasn't caught up yet and
> > > there's a lot of characters still in the circular buffer.
> > >
> > > Now, 1) can be mitigated by increasing the circular buffer size. A value
> > > that seems to give reliably good results in 2 << CONFIG_LOG_BUF_SHIFT.
> > >
> > Yes please.
>
> As I explained elsewhere, I actually went and implemented this. But
> given the nature of buffering, this ends up making the TCU completely
> useless as a console because in case of a crash, the system will stop
> working with a large number of characters still stuck in the buffer.
> And that's especially bad in case of a crash because those last
> characters that get stuck in the buffer are the most relevant ones
> because they contain the stack dump.
>
I don't question the utility of TCU. I just wonder if mailbox api
should provide a backdoor for atomic busy-wait in order to support a
sub-optimal hw+fw design.
> > > I thought that I could also mitigate 2) by busy looping in the TCU driver,
> > > but it turns out that that doesn't work. The reason is that since we are
> > > in atomic context with all interrupts disabled, the mailbox won't ever
> > > consume any new characters, so the read pointer in the circular buffer
> > > won't increment, leaving me with no condition upon which to loop that
> > > would work.
> > >
> > So you want to be able to rely on an emulated console (running on a
> > totally different subsystem) to dump development-phase early-boot
> > logs? At the cost of legitimizing busy looping in atomic context - one
> > random driver messing up the api for ever. Maybe you could have the
> > ring buffer in some shmem and only pass the number of valid characters
> > in it, to the remote?
>
> First of all, this is not about development-phase early-boot messages.
> We're talking about the system console here. This is what everyone will
> want to be using when developing on this device. Sure at some point you
> may end up with a system that works and you can have the console on the
> network or an attached display or whatever, but even then you may still
> want to attach to the console if you ever run into issues where the
> system doesn't come up.
>
> Secondly, I don't understand why you think this is an emulated console.
>
It is emulated/virtual because Linux doesn't put characters on a
physical bus. The data is simply handed forward to a remote entity.
> Lastly, I don't understand why you think we're messing up the API here.
> The proposal in this series doesn't even change any of the API, but it
> makes it aware of the state of interrupts internally so that it can do
> the right thing depending on the call stack. The other proposal, in v3,
> is more explicit in that it adds new API to flush the mailbox. The new
> API is completely optional and I even offered to document it as being
> discouraged because it involves busy looping. At the same time it does
> solve a real problem and it doesn't impact any existing mailbox drivers
> nor any of their users (because it is completely opt-in).
>
The 'flush' api is going to have no use other than implement
busy-waits. I am afraid people are simply going to take it easy and
copy the busy-waits from the test/verification codes.
"discouraging" seldom works because the developer comes with the
failproof excuse "the h/w doesn't provide any other way". Frankly I
would like to push back on such designs.
Anyways, let us add the new 'flush' api.
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 01/10] mailbox: Support blocking transfers in atomic context
From: Jassi Brar @ 2018-12-08 5:51 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Devicetree List, Greg KH, mliljeberg, Mikko Perttunen, talho,
Thierry Reding, linux-serial, jslaby, linux-tegra, ppessi,
Jon Hunter, linux-arm-kernel
In-Reply-To: <4f7a4211-47ee-1114-0974-a3b402178106@kapsi.fi>
On Fri, Dec 7, 2018 at 11:50 AM Mikko Perttunen <cyndis@kapsi.fi> wrote:
>
> On 07/12/2018 11.26, Jassi Brar wrote:
> >> I thought that I could also mitigate 2) by busy looping in the TCU driver,
> >> but it turns out that that doesn't work. The reason is that since we are
> >> in atomic context with all interrupts disabled, the mailbox won't ever
> >> consume any new characters, so the read pointer in the circular buffer
> >> won't increment, leaving me with no condition upon which to loop that
> >> would work.
> >>
> > So you want to be able to rely on an emulated console (running on a
> > totally different subsystem) to dump development-phase early-boot
> > logs? At the cost of legitimizing busy looping in atomic context - one
> > random driver messing up the api for ever. Maybe you could have the
> > ring buffer in some shmem and only pass the number of valid characters
> > in it, to the remote?
> >
>
> I would like to note that this is the one and only console interface
> that exists on these systems, for both development phase and production.
> Other UARTs are not externally accessible on the systems, or they are
> comparatively difficult to access as they aren't intended to be used as
> consoles in the system design.
> The combination of hardware and firmware
> implementing the console is black box from software's point of view
> (similarly to any other UART HW). The interface has also been fixed at
> an early system design phase, as there are many operating systems
> running on these boards, each with their own drivers.
>
That is the saddest part - someone, who writes test cases for the h/w
team and with almost no knowledge of how OSes work, decides how the
firmware is going to work and calls it done. Then the Linux is left to
deal with the mess as we "can't do anything about it".
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] soc: bcm2835: sync firmware properties with downstream
From: Eric Anholt @ 2018-12-08 5:49 UTC (permalink / raw)
To: Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden,
Arnd Bergmann
Cc: Stefan Wahren, bcm-kernel-feedback-list, linux-rpi-kernel,
linux-arm-kernel
In-Reply-To: <1544206871-15725-1-git-send-email-stefan.wahren@i2se.com>
[-- Attachment #1.1: Type: text/plain, Size: 315 bytes --]
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Add latest firmware property tags from the latest Raspberry Pi downstream
> kernel. This is needed to use the reboot notify in the following
> commit.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
These are:
Reviewed-by: Eric Anholt <eric@anholt.net>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: ti: k3-am654: Add Support for MMC/SD
From: Vignesh R @ 2018-12-08 5:26 UTC (permalink / raw)
To: Faiz Abbas, linux-arm-kernel, nm, t-kristo
Cc: mark.rutland, devicetree, ulf.hansson, linux-kernel, kishon,
robh+dt, adrian.hunter, michal.simek
In-Reply-To: <20181207084233.13700-2-faiz_abbas@ti.com>
On 07/12/18 2:12 PM, Faiz Abbas wrote:
> There are two MMC host controller instances present on the TI's
> Am654 SOCs. Add device tree nodes for the same.
>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 28 ++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index 916434839603..d07212f16a81 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -129,4 +129,32 @@
> clocks = <&k3_clks 113 1>;
> power-domains = <&k3_pds 113>;
> };
> +
> + sdhci0: sdhci@4f80000 {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4f80000 0x0 0x260>, <0x0 0x4f90000 0x0 0x134>;
> + power-domains = <&k3_pds 47>;
> + clocks = <&k3_clks 47 0>, <&k3_clks 47 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
> + sdhci-caps-mask = <0x80000007 0x0>;
> + mmc-ddr-1_8v;
> + ti,otap-del-sel = <0x2>;
> + ti,trm-icp = <0x8>;
> + status = "disabled";
> + };
Please drop "status=disabled" from dtsi. Can be disabled as required in
the board dts.
> +
> + sdhci1: sdhci@4fa0000 {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4fa0000 0x0 0x260>, <0x0 0x4fb0000 0x0 0x134>;
> + power-domains = <&k3_pds 48>;
> + clocks = <&k3_clks 48 0>, <&k3_clks 48 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
> + sdhci-caps-mask = <0x80000007 0x0>;
> + mmc-ddr-1_8v;
> + ti,otap-del-sel = <0x2>;
> + ti,trm-icp = <0x8>;
> + status = "disabled";
> + };
> };
>
--
Regards
Vignesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Qualcomm Driver updates for 4.21 - Part 2
From: Andy Gross @ 2018-12-08 5:13 UTC (permalink / raw)
To: arm
Cc: Arnd Bergmann, linux-arm-msm, linux-kernel, Bjorn Andersson,
Kevin Hilman, Olof Johansson, linux-arm-kernel
In-Reply-To: <1544245994-4228-1-git-send-email-andy.gross@linaro.org>
The following changes since commit b601f73130a375c912d9f2ec93c5f3cea5d6a3da:
drm: msm: Check cmd_db_read_aux_data() for failure (2018-11-29 17:41:53 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.21-2
for you to fetch changes up to 92def04bd7b46f5b186f985d5c9d3804858c3c2f:
MAINTAINERS: Change Todor Tomov's email address (2018-12-05 16:45:34 -0600)
----------------------------------------------------------------
Qualcomm ARM Based Driver Updates for v4.21 Part 2
* Fix MAINTAINERS email address for Todor
* Fix SCM compilation error
----------------------------------------------------------------
Jonathan Marek (1):
firmware: qcom: scm: fix compilation error when disabled
Todor Tomov (1):
MAINTAINERS: Change Todor Tomov's email address
MAINTAINERS | 2 +-
include/linux/qcom_scm.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 DT updates for 4.21 - Part 2
From: Andy Gross @ 2018-12-08 5:13 UTC (permalink / raw)
To: arm
Cc: Arnd Bergmann, linux-arm-msm, linux-kernel, Bjorn Andersson,
Kevin Hilman, Olof Johansson, linux-arm-kernel
The following changes since commit 70827d9f6bc4f481fafe790dd6654ba568526768:
arm64: dts: qcom: msm8998: Fix compatible of scm node (2018-11-30 07:59:02 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm64-for-4.21-2
for you to fetch changes up to 1504b91c819359b574b55c269c850352260b8d19:
arm64: dts: msm8996: Use dwc3-qcom glue driver for USB (2018-12-07 14:10:56 -0600)
----------------------------------------------------------------
Qualcomm ARM64 Updates for v4.21 Part 2
* Switch to use dwc3-qcom glue driver on MSM8996
* Fix issue with xo clk name on MSM8998
* Add cooling maps on MSM8916
* Add UART nodes on SDM845
* Add camera subsystem support on MSM8996 and MSM8916
----------------------------------------------------------------
Andy Gross (1):
arm64: dts: qcom: msm8998: Fixup clock to use xo_board
Manu Gautam (1):
arm64: dts: msm8996: Use dwc3-qcom glue driver for USB
Matthias Kaehlcke (1):
arm64: dts: qcom: sdm845: Add UART nodes
Todor Tomov (6):
arm64: dts: qcom: msm8916: Add IOMMU sub-node for VFE context bank
arm64: dts: qcom: msm8916: Add CAMSS support
arm64: dts: qcom: Add Camera Control Interface pinctrls
arm64: dts: qcom: Add pinctrls for camera sensors
arm64: dts: qcom: msm8996: Add VFE SMMU node
arm64: dts: qcom: msm8996: Add CAMSS support
Viresh Kumar (1):
arm64: dts: msm8916: Add all CPUs in cooling maps
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 6 +-
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 76 ++++++++
arch/arm64/boot/dts/qcom/msm8916.dtsi | 97 +++++++++-
arch/arm64/boot/dts/qcom/msm8996-pins.dtsi | 120 ++++++++++++
arch/arm64/boot/dts/qcom/msm8996.dtsi | 162 +++++++++++++++-
arch/arm64/boot/dts/qcom/msm8998.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 270 +++++++++++++++++++++++++++
7 files changed, 725 insertions(+), 9 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 01/34] kbuild: Add support for DT binding schema checks
From: Masahiro Yamada @ 2018-12-08 4:47 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, DTML, kumar.gala, arm-soc, darknighte,
Jonathan Corbet, Frank Rowand, open list:DOCUMENTATION,
Linux Kernel Mailing List, Linux Kbuild mailing list,
Michal Marek, grant.likely, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20181203213223.16986-2-robh@kernel.org>
Hi Rob,
On Tue, Dec 4, 2018 at 6:32 AM Rob Herring <robh@kernel.org> wrote:
>
> This adds the build infrastructure for checking DT binding schema
> documents and validating dts files using the binding schema.
>
> Check DT binding schema documents:
> make dt_binding_check
>
> Build dts files and check using DT binding schema:
> make dtbs_check
>
> Optionally, DT_SCHEMA_FILES can passed in with a schema file(s) to use
> for validation. This makes it easier to find and fix errors generated by
> a specific schema.
>
> Currently, the validation targets are separate from a normal build to
> avoid a hard dependency on the external DT schema project and because
> there are lots of warnings generated.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Michal Marek <michal.lkml@markovi.net>
> Cc: linux-doc@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kbuild@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .gitignore | 1 +
> Documentation/Makefile | 2 +-
> Documentation/devicetree/bindings/.gitignore | 1 +
> Documentation/devicetree/bindings/Makefile | 33 ++++++++++++++++++++
> Makefile | 11 +++++--
> scripts/Makefile.lib | 24 ++++++++++++--
> 6 files changed, 67 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/.gitignore
> create mode 100644 Documentation/devicetree/bindings/Makefile
>
> diff --git a/.gitignore b/.gitignore
> index 97ba6b79834c..a20ac26aa2f5 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -15,6 +15,7 @@
> *.bin
> *.bz2
> *.c.[012]*.*
> +*.dt.yaml
> *.dtb
> *.dtb.S
> *.dwo
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 2ca77ad0f238..9786957c6a35 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -2,7 +2,7 @@
> # Makefile for Sphinx documentation
> #
>
> -subdir-y :=
> +subdir-y := devicetree/bindings/
>
> # You can set these variables from the command line.
> SPHINXBUILD = sphinx-build
> diff --git a/Documentation/devicetree/bindings/.gitignore b/Documentation/devicetree/bindings/.gitignore
> new file mode 100644
> index 000000000000..d9194c02dd08
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/.gitignore
> @@ -0,0 +1 @@
> +*.example.dts
> diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
> new file mode 100644
> index 000000000000..ee0110dd8131
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/Makefile
> @@ -0,0 +1,33 @@
> +# SPDX-License-Identifier: GPL-2.0
> +DT_DOC_CHECKER ?= dt-doc-validate
> +DT_EXTRACT_EX ?= dt-extract-example
> +DT_MK_SCHEMA ?= dt-mk-schema
> +DT_MK_SCHEMA_FLAGS := $(if $(DT_SCHEMA_FILES), -u)
> +
> +quiet_cmd_chk_binding = CHKDT $<
> + cmd_chk_binding = (set -e; \
> + $(DT_DOC_CHECKER) $< ; \
> + mkdir -p $(dir $@) ; \
> + $(DT_EXTRACT_EX) $< > $@ )
> +
> +$(obj)/%.example.dts: $(src)/%.yaml FORCE
> + $(call if_changed,chk_binding)
> +
> +DT_TMP_SCHEMA := .schema.yaml.tmp
> +extra-y += $(DT_TMP_SCHEMA)
> +
> +quiet_cmd_mk_schema = SCHEMA $@
> + cmd_mk_schema = mkdir -p $(obj); \
> + rm -f $@; \
> + $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $<
I think '$<' is wrong.
'$<' is replaced with the first prerequisite.
You can easily check what is happening here.
$ cat Documentation/devicetree/bindings/..schema.yaml.tmp.cmd
cmd_Documentation/devicetree/bindings/.schema.yaml.tmp := mkdir -p
Documentation/devicetree/bindings; rm -f
Documentation/devicetree/bindings/.schema.yaml.tmp; dt-mk-schema -o
Documentation/devicetree/bindings/.schema.yaml.tmp
Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml
So, the dt-validater will check only binding from ti,davinci.yaml,
which is almost useless.
If I understand it correctly,
.schema.yaml.tmp should contain all binding yaml.
I fixed it up like follows:
diff --git a/Documentation/devicetree/bindings/Makefile
b/Documentation/devicetree/bindings/Makefile
index ee0110d..267458f 100644
--- a/Documentation/devicetree/bindings/Makefile
+++ b/Documentation/devicetree/bindings/Makefile
@@ -19,7 +19,7 @@ extra-y += $(DT_TMP_SCHEMA)
quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = mkdir -p $(obj); \
rm -f $@; \
- $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $<
+ $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@
$(filter-out FORCE, $^)
DT_DOCS = $(shell cd $(srctree)/$(src) && find * -name '*.yaml')
DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS))
Then, I see another error.
SCHEMA Documentation/devicetree/bindings/.schema.yaml.tmp
Traceback (most recent call last):
File "/home/masahiro/ref/yaml-bindings/tools/dt-mk-schema", line 32,
in <module>
schemas = dtschema.process_schemas(args.schemas, core_schema=(not
args.useronly))
File "/usr/local/lib/python3.5/dist-packages/dtschema-0.0.1-py3.5.egg/dtschema/lib.py",
line 359, in process_schemas
sch = process_schema(os.path.abspath(filename))
File "/usr/local/lib/python3.5/dist-packages/dtschema-0.0.1-py3.5.egg/dtschema/lib.py",
line 314, in process_schema
schema = load_schema(filename)
File "/usr/local/lib/python3.5/dist-packages/dtschema-0.0.1-py3.5.egg/dtschema/lib.py",
line 80, in load_schema
return yaml.load(f.read())
File "/usr/lib/python3.5/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd0 in position
0: invalid continuation byte
Documentation/devicetree/bindings/Makefile:33: recipe for target
'Documentation/devicetree/bindings/.schema.yaml.tmp' failed
make[1]: *** [Documentation/devicetree/bindings/.schema.yaml.tmp] Error 1
Makefile:1278: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
BTW, I cannot build *.dt.yaml
DTC arch/arm/boot/dts/alpine-db.dt.yaml
FATAL ERROR: Unknown output format "yaml"
scripts/Makefile.lib:313: recipe for target
'arch/arm/boot/dts/alpine-db.dt.yaml' failed
make[1]: *** [arch/arm/boot/dts/alpine-db.dt.yaml] Error 1
make[1]: *** Deleting file 'arch/arm/boot/dts/alpine-db.dt.yaml'
Makefile:1262: recipe for target 'dtbs_check' failed
I use linux-next.
script/dtc/dtc does not understand '-O yaml'
I also tried the upstream DTC project with no success.
Where can I get dtc with yaml support?
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 4/5] ARM: dts: imx5: add gpu nodes
From: Shawn Guo @ 2018-12-08 3:24 UTC (permalink / raw)
To: Jonathan Marek
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
freedreno, Sascha Hauer, open list, Rob Herring, Chris.Healy,
Pengutronix Kernel Team, Fabio Estevam, festevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
NXP Linux Team
In-Reply-To: <20181204151702.8514-4-jonathan@marek.ca>
On Tue, Dec 04, 2018 at 10:17:00AM -0500, Jonathan Marek wrote:
> This adds the gpu nodes for the adreno 200 GPU on iMX51 and iMX53, now
> supported by the freedreno driver.
>
> The compatible for the iMX51 uses a patchid of 1, which is used by drm/msm
> driver to identify the smaller 128KiB GMEM size.
>
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: ls1012a: Add FRWY-LS1012A device tree binding
From: Shawn Guo @ 2018-12-08 2:22 UTC (permalink / raw)
To: Pramod Kumar, Rob Herring
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Leo Li
In-Reply-To: <20181031064809.GF10386@tiger>
On Wed, Oct 31, 2018 at 02:48:12PM +0800, Shawn Guo wrote:
> On Fri, Oct 26, 2018 at 08:45:26AM +0000, Pramod Kumar wrote:
> > LS1012A-FRWY is an ls1012a based SoC board
> > Add device tree binding for LS1012A-FRWY board
> >
> > Signed-off-by: Pramod Kumar <pramod.kumar_1@nxp.com>
>
> It should really be sent together with "arm64: dts: ls1012a: Add
> FRWY-LS1012A board support" as a patch series.
>
> Applied, thanks.
I dropped this patch from my 4.21 queue for now, as Rob is moving the
bindings to json-schema during this development cycle. I will add the
compatible back using json-schema format after 4.21-rc1 is available.
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: Add compatible string for LS1028A-QDS
From: Shawn Guo @ 2018-12-08 2:14 UTC (permalink / raw)
To: Bhaskar Upadhaya, Rob Herring
Cc: devicetree@vger.kernel.org, Sudhanshu Gupta, Harninder Rai,
Rajesh Bhagat, Leo Li, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181128024149.GC20643@dragon>
On Wed, Nov 28, 2018 at 10:41:50AM +0800, Shawn Guo wrote:
> On Wed, Nov 14, 2018 at 05:30:50AM +0000, Bhaskar Upadhaya wrote:
> > Signed-off-by: Sudhanshu Gupta <sudhanshu.gupta@nxp.com>
> > Signed-off-by: Rai Harninder <harninder.rai@nxp.com>
> > Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com>
> > Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > changes in v3:
> > no change
> >
> > Documentation/devicetree/bindings/arm/fsl.txt | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
>
> Applied both, thanks.
I dropped this patch from my 4.21 queue for now, as Rob is moving the
bindings to json-schema during this development cycle. I will add the
compatible back using json-schema format after 4.21-rc1 is available.
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 18/34] dt-bindings: arm: Convert FSL board/soc bindings to json-schema
From: Shawn Guo @ 2018-12-08 1:58 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Kumar Gala, ARM-SoC Maintainers,
Sean Hudson, Frank Rowand, linux-kernel@vger.kernel.org,
Grant Likely, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqK5nBdk-MiuTPMxr9oXqXnLqeMU3vtZi6AnT9V35_W55A@mail.gmail.com>
On Thu, Dec 06, 2018 at 05:33:13PM -0600, Rob Herring wrote:
> On Wed, Dec 5, 2018 at 8:32 PM Shawn Guo <shawnguo@kernel.org> wrote:
> >
> > On Mon, Dec 03, 2018 at 03:32:07PM -0600, Rob Herring wrote:
> > > Convert Freescale SoC bindings to DT schema format using json-schema.
> > >
> > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > Cc: devicetree@vger.kernel.org
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > ---
> > > .../devicetree/bindings/arm/armadeus.txt | 6 -
> > > Documentation/devicetree/bindings/arm/bhf.txt | 6 -
> > > .../bindings/arm/compulab-boards.txt | 25 --
> > > Documentation/devicetree/bindings/arm/fsl.txt | 229 ------------------
> > > .../devicetree/bindings/arm/fsl.yaml | 214 ++++++++++++++++
> >
> > Rob,
> >
> > I do have any changes on bindings/arm/fsl.txt queued for 4.21 on my
> > tree, so please send it via your tree.
>
> What about:
>
> c386f362957b dt-bindings: Add compatible string for LS1028A-QDS
> 3671cd57de06 dt-bindings: ls1012a: Add FRWY-LS1012A device tree binding
Ah, sorry, I only checked on imx/dt branch and forgot imx/dt64. I will
drop the changes on fsl.txt and update fsl.yaml after it hits mainline.
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: Add missing ranges for dra7 mcasp l3 ports
From: Tony Lindgren @ 2018-12-08 0:54 UTC (permalink / raw)
To: linux-omap
Cc: Peter Ujfalusi, devicetree, Benoît Cousson, linux-arm-kernel
We need to add mcasp l3 port ranges for mcasp to use a correct l3
data port address for dma. And we're also missing the optional clocks
that we have tagged with HWMOD_OPT_CLKS_NEEDED in omap_hwmod_7xx_data.c.
Note that for reading the module revision register HWMOD_OPT_CLKS_NEEDED
do not seem to be needed. So they could be probably directly managed
only by the mcasp driver, and then we could leave them out for the
interconnect target module.
Fixes: 4ed0dfe3cf39 ("ARM: dts: dra7: Move l4 child devices to probe
them with ti-sysc")
Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/dra7-l4.dtsi | 92 ++++++++++++++++++++++++----------
1 file changed, 66 insertions(+), 26 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -2296,7 +2296,15 @@
reg-names = "ap", "la", "ia0", "ia1", "ia2";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x00000000 0x48400000 0x400000>; /* segment 0 */
+ ranges = <0x00000000 0x48400000 0x400000>, /* segment 0 */
+ <0x45800000 0x45800000 0x400000>, /* L3 data port */
+ <0x45c00000 0x45c00000 0x400000>, /* L3 data port */
+ <0x46000000 0x46000000 0x400000>, /* L3 data port */
+ <0x48436000 0x48436000 0x400000>, /* L3 data port */
+ <0x4843a000 0x4843a000 0x400000>, /* L3 data port */
+ <0x4844c000 0x4844c000 0x400000>, /* L3 data port */
+ <0x48450000 0x48450000 0x400000>, /* L3 data port */
+ <0x48454000 0x48454000 0x400000>; /* L3 data port */
segment@0 { /* 0x48400000 */
compatible = "simple-bus";
@@ -2364,7 +2372,15 @@
<0x0005b000 0x0005b000 0x001000>, /* ap 59 */
<0x0005c000 0x0005c000 0x001000>, /* ap 60 */
<0x0005d000 0x0005d000 0x001000>, /* ap 61 */
- <0x0005e000 0x0005e000 0x001000>; /* ap 62 */
+ <0x0005e000 0x0005e000 0x001000>, /* ap 62 */
+ <0x45800000 0x45800000 0x400000>, /* L3 data port */
+ <0x45c00000 0x45c00000 0x400000>, /* L3 data port */
+ <0x46000000 0x46000000 0x400000>, /* L3 data port */
+ <0x48436000 0x48436000 0x400000>, /* L3 data port */
+ <0x4843a000 0x4843a000 0x400000>, /* L3 data port */
+ <0x4844c000 0x4844c000 0x400000>, /* L3 data port */
+ <0x48450000 0x48450000 0x400000>, /* L3 data port */
+ <0x48454000 0x48454000 0x400000>; /* L3 data port */
target-module@20000 { /* 0x48420000, ap 47 02.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
@@ -2727,11 +2743,14 @@
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): ipu_pwrdm, ipu_clkdm */
- clocks = <&ipu_clkctrl DRA7_IPU_MCASP1_CLKCTRL 0>;
- clock-names = "fck";
+ clocks = <&ipu_clkctrl DRA7_IPU_MCASP1_CLKCTRL 0>,
+ <&ipu_clkctrl DRA7_IPU_MCASP1_CLKCTRL 24>,
+ <&ipu_clkctrl DRA7_IPU_MCASP1_CLKCTRL 28>;
+ clock-names = "fck", "ahclkx", "ahclkr";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x60000 0x2000>;
+ ranges = <0x0 0x60000 0x2000>,
+ <0x45800000 0x45800000 0x400000>;
mcasp1: mcasp@0 {
compatible = "ti,dra7-mcasp-audio";
@@ -2761,11 +2780,14 @@
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
- clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP2_CLKCTRL 0>;
- clock-names = "fck";
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP2_CLKCTRL 0>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP2_CLKCTRL 24>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP2_CLKCTRL 28>;
+ clock-names = "fck", "ahclkx", "ahclkr";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x64000 0x2000>;
+ ranges = <0x0 0x64000 0x2000>,
+ <0x45c00000 0x45c00000 0x400000>;
mcasp2: mcasp@0 {
compatible = "ti,dra7-mcasp-audio";
@@ -2795,11 +2817,14 @@
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
- clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL 0>;
- clock-names = "fck";
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL 0>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL 24>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL 28>;
+ clock-names = "fck", "ahclkx", "ahclkr";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x68000 0x2000>;
+ ranges = <0x0 0x68000 0x2000>,
+ <0x46000000 0x46000000 0x400000>;
mcasp3: mcasp@0 {
compatible = "ti,dra7-mcasp-audio";
@@ -2828,11 +2853,14 @@
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
- clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL 0>;
- clock-names = "fck";
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL 0>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL 24>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL 28>;
+ clock-names = "fck", "ahclkx", "ahclkr";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x6c000 0x2000>;
+ ranges = <0x0 0x6c000 0x2000>,
+ <0x48436000 0x48436000 0x400000>;
mcasp4: mcasp@0 {
compatible = "ti,dra7-mcasp-audio";
@@ -2861,11 +2889,14 @@
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
- clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL 0>;
- clock-names = "fck";
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL 0>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL 24>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL 28>;
+ clock-names = "fck", "ahclkx", "ahclkr";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x70000 0x2000>;
+ ranges = <0x0 0x70000 0x2000>,
+ <0x4843a000 0x4843a000 0x400000>;
mcasp5: mcasp@0 {
compatible = "ti,dra7-mcasp-audio";
@@ -2894,11 +2925,14 @@
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
- clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL 0>;
- clock-names = "fck";
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL 0>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL 24>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL 28>;
+ clock-names = "fck", "ahclkx", "ahclkr";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x74000 0x2000>;
+ ranges = <0x0 0x74000 0x2000>,
+ <0x4844c000 0x4844c000 0x400000>;
mcasp6: mcasp@0 {
compatible = "ti,dra7-mcasp-audio";
@@ -2927,11 +2961,14 @@
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
- clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 0>;
- clock-names = "fck";
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 0>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 24>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 28>;
+ clock-names = "fck", "ahclkx", "ahclkr";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x78000 0x2000>;
+ ranges = <0x0 0x78000 0x2000>,
+ <0x48450000 0x48450000 0x400000>;
mcasp7: mcasp@0 {
compatible = "ti,dra7-mcasp-audio";
@@ -2960,11 +2997,14 @@
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
- clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP8_CLKCTRL 0>;
- clock-names = "fck";
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP8_CLKCTRL 0>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP8_CLKCTRL 24>,
+ <&l4per2_clkctrl DRA7_L4PER2_MCASP8_CLKCTRL 28>;
+ clock-names = "fck", "ahclkx", "ahclkr";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x7c000 0x2000>;
+ ranges = <0x0 0x7c000 0x2000>,
+ <0x48454000 0x48454000 0x400000>;
mcasp8: mcasp@0 {
compatible = "ti,dra7-mcasp-audio";
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v11 5/8] interconnect: qcom: Add sdm845 interconnect provider driver
From: Georgi Djakov @ 2018-12-08 0:24 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: mark.rutland, sanjayc, maxime.ripard, mturquette, daidavid1,
bjorn.andersson, skannan, abailon, lorenzo.pieralisi,
vincent.guittot, seansw, khilman, evgreen, ksitaraman, devicetree,
arnd, linux-pm, linux-arm-msm, robh+dt, linux-tegra,
linux-arm-kernel, gregkh, rjw, dianders, amit.kucheria,
linux-kernel, thierry.reding
In-Reply-To: <20181207233010.GE14307@google.com>
Hi Matthias,
Thanks for looking into this.
On 8.12.18 1:30, Matthias Kaehlcke wrote:
> Hi Georgi,
>
> not a full review, only one thing I just stumbled across:
>
> On Fri, Dec 07, 2018 at 05:29:14PM +0200, Georgi Djakov wrote:
>> From: David Dai <daidavid1@codeaurora.org>
>>
>> Introduce Qualcomm SDM845 specific provider driver using the
>> interconnect framework.
>>
>> Signed-off-by: David Dai <daidavid1@codeaurora.org>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> ---
>> .../bindings/interconnect/qcom,sdm845.txt | 24 +
>> drivers/interconnect/Kconfig | 5 +
>> drivers/interconnect/Makefile | 1 +
>> drivers/interconnect/qcom/Kconfig | 13 +
>> drivers/interconnect/qcom/Makefile | 5 +
>> drivers/interconnect/qcom/sdm845.c | 836 ++++++++++++++++++
>> .../dt-bindings/interconnect/qcom,sdm845.h | 143 +++
>> 7 files changed, 1027 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
>> create mode 100644 drivers/interconnect/qcom/Kconfig
>> create mode 100644 drivers/interconnect/qcom/Makefile
>> create mode 100644 drivers/interconnect/qcom/sdm845.c
>> create mode 100644 include/dt-bindings/interconnect/qcom,sdm845.h
>>
>> ...
>>
>> diff --git a/drivers/interconnect/qcom/sdm845.c b/drivers/interconnect/qcom/sdm845.c
>> new file mode 100644
>> index 000000000000..f594dd6f500f
>> --- /dev/null
>> +++ b/drivers/interconnect/qcom/sdm845.c
>>
>> ...
>>
>> +static int qcom_icc_bcm_init(struct qcom_icc_bcm *bcm, struct device *dev)
>> +{
>> + struct qcom_icc_node *qn;
>> + int ret, i;
>> +
>> + bcm->addr = cmd_db_read_addr(bcm->name);
>> + if (!bcm->addr) {
>> + dev_err(dev, "%s could not find RPMh address\n",
>> + bcm->name);
>> + return -EINVAL;
>> + }
>> +
>> + if (cmd_db_read_aux_data_len(bcm->name) < sizeof(struct bcm_db)) {
>> + dev_err(dev, "%s command db missing or partial aux data\n",
>> + bcm->name);
>> + return -EINVAL;
>> + }
>
> cmd_db_read_aux_data_len() is in the process of being removed, see
> ed3cafa79ea7 ("soc: qcom: cmd-db: Stop memcpy()ing in
> cmd_db_read_aux_data()") in arm-soc/for-next
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/commit/?h=for-next&id=ed3cafa79ea756be653d22087c017af95ea78a49
Yes, exactly. I have a fix that lives as a separate patch [8/8] and will squash it here.
BR,
Georgi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox