* [PATCH v3 1/2] iommu/io-pgtable-arm: Add support for ARM_ADRENO_GPU_LPAE io-pgtable format
From: Jordan Crouse @ 2019-08-07 22:21 UTC (permalink / raw)
To: freedreno
Cc: Rob Herring, Will Deacon, jean-philippe.brucker, linux-arm-msm,
Joerg Roedel, linux-kernel, iommu, Zhen Lei, robin.murphy,
linux-arm-kernel
In-Reply-To: <1565216500-28506-1-git-send-email-jcrouse@codeaurora.org>
Add a new sub-format ARM_ADRENO_GPU_LPAE to set up TTBR0 and TTBR1 for
use by the Adreno GPU. This will allow The GPU driver to map global
buffers in the TTBR1 and leave the TTBR0 configured but unset and
free to be changed dynamically by the GPU.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/iommu/io-pgtable-arm.c | 214 ++++++++++++++++++++++++++++++++++++++---
drivers/iommu/io-pgtable.c | 1 +
include/linux/io-pgtable.h | 2 +
3 files changed, 202 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 161a7d5..8eb0dbb 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -112,13 +112,19 @@
#define ARM_32_LPAE_TCR_EAE (1 << 31)
#define ARM_64_LPAE_S2_TCR_RES1 (1 << 31)
+#define ARM_LPAE_TCR_EPD0 (1 << 7)
#define ARM_LPAE_TCR_EPD1 (1 << 23)
#define ARM_LPAE_TCR_TG0_4K (0 << 14)
#define ARM_LPAE_TCR_TG0_64K (1 << 14)
#define ARM_LPAE_TCR_TG0_16K (2 << 14)
+#define ARM_LPAE_TCR_TG1_4K (0 << 30)
+#define ARM_LPAE_TCR_TG1_64K (1 << 30)
+#define ARM_LPAE_TCR_TG1_16K (2 << 30)
+
#define ARM_LPAE_TCR_SH0_SHIFT 12
+#define ARM_LPAE_TCR_SH1_SHIFT 28
#define ARM_LPAE_TCR_SH0_MASK 0x3
#define ARM_LPAE_TCR_SH_NS 0
#define ARM_LPAE_TCR_SH_OS 2
@@ -126,6 +132,8 @@
#define ARM_LPAE_TCR_ORGN0_SHIFT 10
#define ARM_LPAE_TCR_IRGN0_SHIFT 8
+#define ARM_LPAE_TCR_ORGN1_SHIFT 26
+#define ARM_LPAE_TCR_IRGN1_SHIFT 24
#define ARM_LPAE_TCR_RGN_MASK 0x3
#define ARM_LPAE_TCR_RGN_NC 0
#define ARM_LPAE_TCR_RGN_WBWA 1
@@ -136,6 +144,7 @@
#define ARM_LPAE_TCR_SL0_MASK 0x3
#define ARM_LPAE_TCR_T0SZ_SHIFT 0
+#define ARM_LPAE_TCR_T1SZ_SHIFT 16
#define ARM_LPAE_TCR_SZ_MASK 0xf
#define ARM_LPAE_TCR_PS_SHIFT 16
@@ -152,6 +161,14 @@
#define ARM_LPAE_TCR_PS_48_BIT 0x5ULL
#define ARM_LPAE_TCR_PS_52_BIT 0x6ULL
+#define ARM_LPAE_TCR_SEP_SHIFT 47
+#define ARM_LPAE_TCR_SEP_31 (0x0ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_35 (0x1ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_39 (0x2ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_41 (0x3ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_43 (0x4ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_UPSTREAM (0x7ULL << ARM_LPAE_TCR_SEP_SHIFT)
+
#define ARM_LPAE_MAIR_ATTR_SHIFT(n) ((n) << 3)
#define ARM_LPAE_MAIR_ATTR_MASK 0xff
#define ARM_LPAE_MAIR_ATTR_DEVICE 0x04
@@ -426,7 +443,8 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
arm_lpae_iopte pte;
if (data->iop.fmt == ARM_64_LPAE_S1 ||
- data->iop.fmt == ARM_32_LPAE_S1) {
+ data->iop.fmt == ARM_32_LPAE_S1 ||
+ data->iop.fmt == ARM_ADRENO_GPU_LPAE) {
pte = ARM_LPAE_PTE_nG;
if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
pte |= ARM_LPAE_PTE_AP_RDONLY;
@@ -497,6 +515,21 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
return ret;
}
+static int arm_adreno_gpu_lpae_map(struct io_pgtable_ops *ops,
+ unsigned long iova, phys_addr_t paddr, size_t size,
+ int iommu_prot)
+{
+ struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+ unsigned long mask = 1UL << data->iop.cfg.ias;
+
+ /* This configuration expects all iova addresses to be in TTBR1 */
+ if (WARN_ON(iova & mask))
+ return -ERANGE;
+
+ /* Mask off the sign extended bits and map as usual */
+ return arm_lpae_map(ops, iova & (mask - 1), paddr, size, iommu_prot);
+}
+
static void __arm_lpae_free_pgtable(struct arm_lpae_io_pgtable *data, int lvl,
arm_lpae_iopte *ptep)
{
@@ -643,6 +676,22 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
return __arm_lpae_unmap(data, iova, size, lvl + 1, ptep);
}
+static size_t arm_adreno_gpu_lpae_unmap(struct io_pgtable_ops *ops,
+ unsigned long iova, size_t size)
+{
+ struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+ arm_lpae_iopte *ptep = data->pgd;
+ int lvl = ARM_LPAE_START_LVL(data);
+ unsigned long mask = 1UL << data->iop.cfg.ias;
+
+ /* Make sure the sign extend bit is set in the iova */
+ if (WARN_ON(!(iova & mask)))
+ return 0;
+
+ /* Mask off the sign extended bits before unmapping */
+ return __arm_lpae_unmap(data, iova & (mask - 1), size, lvl, ptep);
+}
+
static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
size_t size)
{
@@ -692,6 +741,17 @@ static phys_addr_t arm_lpae_iova_to_phys(struct io_pgtable_ops *ops,
return iopte_to_paddr(pte, data) | iova;
}
+
+static phys_addr_t arm_adreno_gpu_lpae_iova_to_phys(struct io_pgtable_ops *ops,
+ unsigned long iova)
+{
+ struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+ unsigned long mask = 1UL << data->iop.cfg.ias;
+
+ /* Mask off the sign extended bits before translating */
+ return arm_lpae_iova_to_phys(ops, iova & (mask - 1));
+}
+
static void arm_lpae_restrict_pgsizes(struct io_pgtable_cfg *cfg)
{
unsigned long granule, page_sizes;
@@ -771,17 +831,16 @@ arm_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg)
pgd_bits = va_bits - (data->bits_per_level * (data->levels - 1));
data->pgd_size = 1UL << (pgd_bits + ilog2(sizeof(arm_lpae_iopte)));
- data->iop.ops = (struct io_pgtable_ops) {
- .map = arm_lpae_map,
- .unmap = arm_lpae_unmap,
- .iova_to_phys = arm_lpae_iova_to_phys,
- };
return data;
}
-static struct io_pgtable *
-arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
+/*
+ * Common allocation function for S1 pagetables. Set up the TTBR0 region and
+ * allocate a default pagetable
+ */
+static struct arm_lpae_io_pgtable *
+_arm_64_lpae_alloc_pgtable_s1_common(struct io_pgtable_cfg *cfg)
{
u64 reg;
struct arm_lpae_io_pgtable *data;
@@ -845,8 +904,6 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
reg |= (64ULL - cfg->ias) << ARM_LPAE_TCR_T0SZ_SHIFT;
- /* Disable speculative walks through TTBR1 */
- reg |= ARM_LPAE_TCR_EPD1;
cfg->arm_lpae_s1_cfg.tcr = reg;
/* MAIRs */
@@ -870,16 +927,131 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
/* Ensure the empty pgd is visible before any actual TTBR write */
wmb();
- /* TTBRs */
- cfg->arm_lpae_s1_cfg.ttbr[0] = virt_to_phys(data->pgd);
- cfg->arm_lpae_s1_cfg.ttbr[1] = 0;
- return &data->iop;
-
+ return data;
out_free_data:
kfree(data);
return NULL;
}
+
+static struct io_pgtable *
+arm_adreno_gpu_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
+{
+ struct arm_lpae_io_pgtable *data;
+ u64 reg;
+
+ /*
+ * Make sure the ias aligns with the available options for the sign
+ * extension bit
+ */
+ switch (cfg->ias) {
+ case 32:
+ case 36:
+ case 40:
+ case 42:
+ case 44:
+ /*
+ * The SEP will be the highest available bit so adjust the data
+ * size by one to accommodate it
+ */
+ cfg->ias--;
+ break;
+ case 48:
+ /*
+ * IAS of 48 is a special case, it has a dedicated sign
+ * extension bit so we can use the full IAS size
+ */
+ break;
+ default:
+ /* The ias doesn't work for the available SEP options */
+ return NULL;
+ }
+
+ data = _arm_64_lpae_alloc_pgtable_s1_common(cfg);
+ if (!data)
+ return NULL;
+
+ reg = (ARM_LPAE_TCR_SH_IS << ARM_LPAE_TCR_SH1_SHIFT) |
+ (ARM_LPAE_TCR_RGN_WBWA << ARM_LPAE_TCR_IRGN1_SHIFT) |
+ (ARM_LPAE_TCR_RGN_WBWA << ARM_LPAE_TCR_ORGN1_SHIFT);
+
+ switch (ARM_LPAE_GRANULE(data)) {
+ case SZ_4K:
+ reg |= ARM_LPAE_TCR_TG1_4K;
+ break;
+ case SZ_16K:
+ reg |= ARM_LPAE_TCR_TG1_16K;
+ break;
+ case SZ_64K:
+ reg |= ARM_LPAE_TCR_TG1_64K;
+ break;
+ }
+
+ reg |= (64ULL - cfg->ias) << ARM_LPAE_TCR_T1SZ_SHIFT;
+
+ /* Set the sign extension bit */
+ switch (cfg->ias) {
+ case 31:
+ reg |= ARM_LPAE_TCR_SEP_31;
+ break;
+ case 35:
+ reg |= ARM_LPAE_TCR_SEP_35;
+ break;
+ case 39:
+ reg |= ARM_LPAE_TCR_SEP_39;
+ break;
+ case 41:
+ reg |= ARM_LPAE_TCR_SEP_41;
+ break;
+ case 43:
+ reg |= ARM_LPAE_TCR_SEP_43;
+ break;
+ case 48:
+ reg |= ARM_LPAE_TCR_SEP_UPSTREAM;
+ break;
+ }
+
+ cfg->arm_lpae_s1_cfg.tcr |= reg;
+
+ /* Set the allocated pgd to ttbr1 and leave ttbr0 empty */
+ cfg->arm_lpae_s1_cfg.ttbr[0] = 0;
+ cfg->arm_lpae_s1_cfg.ttbr[1] = virt_to_phys(data->pgd);
+
+ /* Set use case specific pgtable helpers */
+ data->iop.ops = (struct io_pgtable_ops) {
+ .map = arm_adreno_gpu_lpae_map,
+ .unmap = arm_adreno_gpu_lpae_unmap,
+ .iova_to_phys = arm_adreno_gpu_lpae_iova_to_phys,
+ };
+
+ return &data->iop;
+}
+
+static struct io_pgtable *
+arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
+{
+ struct arm_lpae_io_pgtable *data;
+
+ data = _arm_64_lpae_alloc_pgtable_s1_common(cfg);
+ if (!data)
+ return NULL;
+
+ /* Disable speculative walks through TTBR1 */
+ cfg->arm_lpae_s1_cfg.tcr |= ARM_LPAE_TCR_EPD1;
+
+ /* Set the pgd to TTBR0 */
+ cfg->arm_lpae_s1_cfg.ttbr[0] = virt_to_phys(data->pgd);
+ cfg->arm_lpae_s1_cfg.ttbr[1] = 0;
+
+ data->iop.ops = (struct io_pgtable_ops) {
+ .map = arm_lpae_map,
+ .unmap = arm_lpae_unmap,
+ .iova_to_phys = arm_lpae_iova_to_phys,
+ };
+
+ return &data->iop;
+}
+
static struct io_pgtable *
arm_64_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
{
@@ -894,6 +1066,12 @@ arm_64_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
if (!data)
return NULL;
+ data->iop.ops = (struct io_pgtable_ops) {
+ .map = arm_lpae_map,
+ .unmap = arm_lpae_unmap,
+ .iova_to_phys = arm_lpae_iova_to_phys,
+ };
+
/*
* Concatenate PGDs at level 1 if possible in order to reduce
* the depth of the stage-2 walk.
@@ -1041,6 +1219,11 @@ struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
.free = arm_lpae_free_pgtable,
};
+struct io_pgtable_init_fns io_pgtable_arm_adreno_gpu_lpae_init_fns = {
+ .alloc = arm_adreno_gpu_lpae_alloc_pgtable,
+ .free = arm_lpae_free_pgtable,
+};
+
struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
.alloc = arm_64_lpae_alloc_pgtable_s2,
.free = arm_lpae_free_pgtable,
@@ -1112,6 +1295,7 @@ static int __init arm_lpae_run_tests(struct io_pgtable_cfg *cfg)
static const enum io_pgtable_fmt fmts[] = {
ARM_64_LPAE_S1,
ARM_64_LPAE_S2,
+ ARM_64_LPAE_TTBR1_S1,
};
int i, j;
diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
index ced53e5..e47ed2d 100644
--- a/drivers/iommu/io-pgtable.c
+++ b/drivers/iommu/io-pgtable.c
@@ -20,6 +20,7 @@ io_pgtable_init_table[IO_PGTABLE_NUM_FMTS] = {
[ARM_64_LPAE_S1] = &io_pgtable_arm_64_lpae_s1_init_fns,
[ARM_64_LPAE_S2] = &io_pgtable_arm_64_lpae_s2_init_fns,
[ARM_MALI_LPAE] = &io_pgtable_arm_mali_lpae_init_fns,
+ [ARM_ADRENO_GPU_LPAE] = &io_pgtable_arm_adreno_gpu_lpae_init_fns,
#endif
#ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S
[ARM_V7S] = &io_pgtable_arm_v7s_init_fns,
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index b5a450a..4871e85 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -13,6 +13,7 @@ enum io_pgtable_fmt {
ARM_64_LPAE_S2,
ARM_V7S,
ARM_MALI_LPAE,
+ ARM_ADRENO_GPU_LPAE,
IO_PGTABLE_NUM_FMTS,
};
@@ -213,5 +214,6 @@ extern struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns;
extern struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns;
extern struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns;
extern struct io_pgtable_init_fns io_pgtable_arm_mali_lpae_init_fns;
+extern struct io_pgtable_init_fns io_pgtable_arm_adreno_gpu_lpae_init_fns;
#endif /* __IO_PGTABLE_H */
--
2.7.4
_______________________________________________
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 v3 0/2] iommu/arm-smmu: Split pagetable support
From: Jordan Crouse @ 2019-08-07 22:21 UTC (permalink / raw)
To: freedreno
Cc: Rob Herring, Will Deacon, jean-philippe.brucker, linux-arm-msm,
Joerg Roedel, linux-kernel, iommu, Zhen Lei, robin.murphy,
linux-arm-kernel
(Sigh, resend. I freaked out my SMTP server)
This is part of an ongoing evolution for enabling split pagetable support for
arm-smmu. Previous versions can be found [1].
In the discussion for v2 Robin pointed out that this is a very Adreno specific
use case and that is exactly true. Not only do we want to configure and use a
pagetable in the TTBR1 space, we also want to configure the TTBR0 region but
not allocate a pagetable for it or touch it until the GPU hardware does so. As
much as I want it to be a generic concept it really isn't.
This revision leans into that idea. Most of the same io-pgtable code is there
but now it is wrapped as an Adreno GPU specific format that is selected by the
compatible string in the arm-smmu device.
Additionally, per Robin's suggestion we are skipping creating a TTBR0 pagetable
to save on wasted memory.
This isn't as clean as I would like it to be but I think that this is a better
direction than trying to pretend that the generic format would work.
I'm tempting fate by posting this and then taking some time off, but I wanted
to try to kick off a conversation or at least get some flames so I can try to
refine this again next week. Please take a look and give some advice on the
direction.
[1] https://patchwork.freedesktop.org/series/63403/
Jordan
Jordan Crouse (2):
iommu/io-pgtable-arm: Add support for ARM_ADRENO_GPU_LPAE io-pgtable
format
iommu/arm-smmu: Add support for Adreno GPU pagetable formats
drivers/iommu/arm-smmu.c | 8 +-
drivers/iommu/io-pgtable-arm.c | 214 ++++++++++++++++++++++++++++++++++++++---
drivers/iommu/io-pgtable.c | 1 +
include/linux/io-pgtable.h | 2 +
4 files changed, 209 insertions(+), 16 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/2] iommu/io-pgtable-arm: Add support for ARM_ADRENO_GPU_LPAE io-pgtable format
From: Jordan Crouse @ 2019-08-07 22:19 UTC (permalink / raw)
To: freedreno
Cc: Rob Herring, Will Deacon, jean-philippe.brucker, linux-arm-msm,
Joerg Roedel, linux-kernel, iommu, Zhen Lei, robin.murphy,
linux-arm-kernel
In-Reply-To: <1565216386-28309-1-git-send-email-jcrouse@codeaurora.org>
Add a new sub-format ARM_ADRENO_GPU_LPAE to set up TTBR0 and TTBR1 for
use by the Adreno GPU. This will allow The GPU driver to map global
buffers in the TTBR1 and leave the TTBR0 configured but unset and
free to be changed dynamically by the GPU.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/iommu/io-pgtable-arm.c | 214 ++++++++++++++++++++++++++++++++++++++---
drivers/iommu/io-pgtable.c | 1 +
include/linux/io-pgtable.h | 2 +
3 files changed, 202 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 161a7d5..8eb0dbb 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -112,13 +112,19 @@
#define ARM_32_LPAE_TCR_EAE (1 << 31)
#define ARM_64_LPAE_S2_TCR_RES1 (1 << 31)
+#define ARM_LPAE_TCR_EPD0 (1 << 7)
#define ARM_LPAE_TCR_EPD1 (1 << 23)
#define ARM_LPAE_TCR_TG0_4K (0 << 14)
#define ARM_LPAE_TCR_TG0_64K (1 << 14)
#define ARM_LPAE_TCR_TG0_16K (2 << 14)
+#define ARM_LPAE_TCR_TG1_4K (0 << 30)
+#define ARM_LPAE_TCR_TG1_64K (1 << 30)
+#define ARM_LPAE_TCR_TG1_16K (2 << 30)
+
#define ARM_LPAE_TCR_SH0_SHIFT 12
+#define ARM_LPAE_TCR_SH1_SHIFT 28
#define ARM_LPAE_TCR_SH0_MASK 0x3
#define ARM_LPAE_TCR_SH_NS 0
#define ARM_LPAE_TCR_SH_OS 2
@@ -126,6 +132,8 @@
#define ARM_LPAE_TCR_ORGN0_SHIFT 10
#define ARM_LPAE_TCR_IRGN0_SHIFT 8
+#define ARM_LPAE_TCR_ORGN1_SHIFT 26
+#define ARM_LPAE_TCR_IRGN1_SHIFT 24
#define ARM_LPAE_TCR_RGN_MASK 0x3
#define ARM_LPAE_TCR_RGN_NC 0
#define ARM_LPAE_TCR_RGN_WBWA 1
@@ -136,6 +144,7 @@
#define ARM_LPAE_TCR_SL0_MASK 0x3
#define ARM_LPAE_TCR_T0SZ_SHIFT 0
+#define ARM_LPAE_TCR_T1SZ_SHIFT 16
#define ARM_LPAE_TCR_SZ_MASK 0xf
#define ARM_LPAE_TCR_PS_SHIFT 16
@@ -152,6 +161,14 @@
#define ARM_LPAE_TCR_PS_48_BIT 0x5ULL
#define ARM_LPAE_TCR_PS_52_BIT 0x6ULL
+#define ARM_LPAE_TCR_SEP_SHIFT 47
+#define ARM_LPAE_TCR_SEP_31 (0x0ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_35 (0x1ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_39 (0x2ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_41 (0x3ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_43 (0x4ULL << ARM_LPAE_TCR_SEP_SHIFT)
+#define ARM_LPAE_TCR_SEP_UPSTREAM (0x7ULL << ARM_LPAE_TCR_SEP_SHIFT)
+
#define ARM_LPAE_MAIR_ATTR_SHIFT(n) ((n) << 3)
#define ARM_LPAE_MAIR_ATTR_MASK 0xff
#define ARM_LPAE_MAIR_ATTR_DEVICE 0x04
@@ -426,7 +443,8 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
arm_lpae_iopte pte;
if (data->iop.fmt == ARM_64_LPAE_S1 ||
- data->iop.fmt == ARM_32_LPAE_S1) {
+ data->iop.fmt == ARM_32_LPAE_S1 ||
+ data->iop.fmt == ARM_ADRENO_GPU_LPAE) {
pte = ARM_LPAE_PTE_nG;
if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
pte |= ARM_LPAE_PTE_AP_RDONLY;
@@ -497,6 +515,21 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
return ret;
}
+static int arm_adreno_gpu_lpae_map(struct io_pgtable_ops *ops,
+ unsigned long iova, phys_addr_t paddr, size_t size,
+ int iommu_prot)
+{
+ struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+ unsigned long mask = 1UL << data->iop.cfg.ias;
+
+ /* This configuration expects all iova addresses to be in TTBR1 */
+ if (WARN_ON(iova & mask))
+ return -ERANGE;
+
+ /* Mask off the sign extended bits and map as usual */
+ return arm_lpae_map(ops, iova & (mask - 1), paddr, size, iommu_prot);
+}
+
static void __arm_lpae_free_pgtable(struct arm_lpae_io_pgtable *data, int lvl,
arm_lpae_iopte *ptep)
{
@@ -643,6 +676,22 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
return __arm_lpae_unmap(data, iova, size, lvl + 1, ptep);
}
+static size_t arm_adreno_gpu_lpae_unmap(struct io_pgtable_ops *ops,
+ unsigned long iova, size_t size)
+{
+ struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+ arm_lpae_iopte *ptep = data->pgd;
+ int lvl = ARM_LPAE_START_LVL(data);
+ unsigned long mask = 1UL << data->iop.cfg.ias;
+
+ /* Make sure the sign extend bit is set in the iova */
+ if (WARN_ON(!(iova & mask)))
+ return 0;
+
+ /* Mask off the sign extended bits before unmapping */
+ return __arm_lpae_unmap(data, iova & (mask - 1), size, lvl, ptep);
+}
+
static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
size_t size)
{
@@ -692,6 +741,17 @@ static phys_addr_t arm_lpae_iova_to_phys(struct io_pgtable_ops *ops,
return iopte_to_paddr(pte, data) | iova;
}
+
+static phys_addr_t arm_adreno_gpu_lpae_iova_to_phys(struct io_pgtable_ops *ops,
+ unsigned long iova)
+{
+ struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+ unsigned long mask = 1UL << data->iop.cfg.ias;
+
+ /* Mask off the sign extended bits before translating */
+ return arm_lpae_iova_to_phys(ops, iova & (mask - 1));
+}
+
static void arm_lpae_restrict_pgsizes(struct io_pgtable_cfg *cfg)
{
unsigned long granule, page_sizes;
@@ -771,17 +831,16 @@ arm_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg)
pgd_bits = va_bits - (data->bits_per_level * (data->levels - 1));
data->pgd_size = 1UL << (pgd_bits + ilog2(sizeof(arm_lpae_iopte)));
- data->iop.ops = (struct io_pgtable_ops) {
- .map = arm_lpae_map,
- .unmap = arm_lpae_unmap,
- .iova_to_phys = arm_lpae_iova_to_phys,
- };
return data;
}
-static struct io_pgtable *
-arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
+/*
+ * Common allocation function for S1 pagetables. Set up the TTBR0 region and
+ * allocate a default pagetable
+ */
+static struct arm_lpae_io_pgtable *
+_arm_64_lpae_alloc_pgtable_s1_common(struct io_pgtable_cfg *cfg)
{
u64 reg;
struct arm_lpae_io_pgtable *data;
@@ -845,8 +904,6 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
reg |= (64ULL - cfg->ias) << ARM_LPAE_TCR_T0SZ_SHIFT;
- /* Disable speculative walks through TTBR1 */
- reg |= ARM_LPAE_TCR_EPD1;
cfg->arm_lpae_s1_cfg.tcr = reg;
/* MAIRs */
@@ -870,16 +927,131 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
/* Ensure the empty pgd is visible before any actual TTBR write */
wmb();
- /* TTBRs */
- cfg->arm_lpae_s1_cfg.ttbr[0] = virt_to_phys(data->pgd);
- cfg->arm_lpae_s1_cfg.ttbr[1] = 0;
- return &data->iop;
-
+ return data;
out_free_data:
kfree(data);
return NULL;
}
+
+static struct io_pgtable *
+arm_adreno_gpu_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
+{
+ struct arm_lpae_io_pgtable *data;
+ u64 reg;
+
+ /*
+ * Make sure the ias aligns with the available options for the sign
+ * extension bit
+ */
+ switch (cfg->ias) {
+ case 32:
+ case 36:
+ case 40:
+ case 42:
+ case 44:
+ /*
+ * The SEP will be the highest available bit so adjust the data
+ * size by one to accommodate it
+ */
+ cfg->ias--;
+ break;
+ case 48:
+ /*
+ * IAS of 48 is a special case, it has a dedicated sign
+ * extension bit so we can use the full IAS size
+ */
+ break;
+ default:
+ /* The ias doesn't work for the available SEP options */
+ return NULL;
+ }
+
+ data = _arm_64_lpae_alloc_pgtable_s1_common(cfg);
+ if (!data)
+ return NULL;
+
+ reg = (ARM_LPAE_TCR_SH_IS << ARM_LPAE_TCR_SH1_SHIFT) |
+ (ARM_LPAE_TCR_RGN_WBWA << ARM_LPAE_TCR_IRGN1_SHIFT) |
+ (ARM_LPAE_TCR_RGN_WBWA << ARM_LPAE_TCR_ORGN1_SHIFT);
+
+ switch (ARM_LPAE_GRANULE(data)) {
+ case SZ_4K:
+ reg |= ARM_LPAE_TCR_TG1_4K;
+ break;
+ case SZ_16K:
+ reg |= ARM_LPAE_TCR_TG1_16K;
+ break;
+ case SZ_64K:
+ reg |= ARM_LPAE_TCR_TG1_64K;
+ break;
+ }
+
+ reg |= (64ULL - cfg->ias) << ARM_LPAE_TCR_T1SZ_SHIFT;
+
+ /* Set the sign extension bit */
+ switch (cfg->ias) {
+ case 31:
+ reg |= ARM_LPAE_TCR_SEP_31;
+ break;
+ case 35:
+ reg |= ARM_LPAE_TCR_SEP_35;
+ break;
+ case 39:
+ reg |= ARM_LPAE_TCR_SEP_39;
+ break;
+ case 41:
+ reg |= ARM_LPAE_TCR_SEP_41;
+ break;
+ case 43:
+ reg |= ARM_LPAE_TCR_SEP_43;
+ break;
+ case 48:
+ reg |= ARM_LPAE_TCR_SEP_UPSTREAM;
+ break;
+ }
+
+ cfg->arm_lpae_s1_cfg.tcr |= reg;
+
+ /* Set the allocated pgd to ttbr1 and leave ttbr0 empty */
+ cfg->arm_lpae_s1_cfg.ttbr[0] = 0;
+ cfg->arm_lpae_s1_cfg.ttbr[1] = virt_to_phys(data->pgd);
+
+ /* Set use case specific pgtable helpers */
+ data->iop.ops = (struct io_pgtable_ops) {
+ .map = arm_adreno_gpu_lpae_map,
+ .unmap = arm_adreno_gpu_lpae_unmap,
+ .iova_to_phys = arm_adreno_gpu_lpae_iova_to_phys,
+ };
+
+ return &data->iop;
+}
+
+static struct io_pgtable *
+arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
+{
+ struct arm_lpae_io_pgtable *data;
+
+ data = _arm_64_lpae_alloc_pgtable_s1_common(cfg);
+ if (!data)
+ return NULL;
+
+ /* Disable speculative walks through TTBR1 */
+ cfg->arm_lpae_s1_cfg.tcr |= ARM_LPAE_TCR_EPD1;
+
+ /* Set the pgd to TTBR0 */
+ cfg->arm_lpae_s1_cfg.ttbr[0] = virt_to_phys(data->pgd);
+ cfg->arm_lpae_s1_cfg.ttbr[1] = 0;
+
+ data->iop.ops = (struct io_pgtable_ops) {
+ .map = arm_lpae_map,
+ .unmap = arm_lpae_unmap,
+ .iova_to_phys = arm_lpae_iova_to_phys,
+ };
+
+ return &data->iop;
+}
+
static struct io_pgtable *
arm_64_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
{
@@ -894,6 +1066,12 @@ arm_64_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
if (!data)
return NULL;
+ data->iop.ops = (struct io_pgtable_ops) {
+ .map = arm_lpae_map,
+ .unmap = arm_lpae_unmap,
+ .iova_to_phys = arm_lpae_iova_to_phys,
+ };
+
/*
* Concatenate PGDs at level 1 if possible in order to reduce
* the depth of the stage-2 walk.
@@ -1041,6 +1219,11 @@ struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
.free = arm_lpae_free_pgtable,
};
+struct io_pgtable_init_fns io_pgtable_arm_adreno_gpu_lpae_init_fns = {
+ .alloc = arm_adreno_gpu_lpae_alloc_pgtable,
+ .free = arm_lpae_free_pgtable,
+};
+
struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
.alloc = arm_64_lpae_alloc_pgtable_s2,
.free = arm_lpae_free_pgtable,
@@ -1112,6 +1295,7 @@ static int __init arm_lpae_run_tests(struct io_pgtable_cfg *cfg)
static const enum io_pgtable_fmt fmts[] = {
ARM_64_LPAE_S1,
ARM_64_LPAE_S2,
+ ARM_64_LPAE_TTBR1_S1,
};
int i, j;
diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
index ced53e5..e47ed2d 100644
--- a/drivers/iommu/io-pgtable.c
+++ b/drivers/iommu/io-pgtable.c
@@ -20,6 +20,7 @@ io_pgtable_init_table[IO_PGTABLE_NUM_FMTS] = {
[ARM_64_LPAE_S1] = &io_pgtable_arm_64_lpae_s1_init_fns,
[ARM_64_LPAE_S2] = &io_pgtable_arm_64_lpae_s2_init_fns,
[ARM_MALI_LPAE] = &io_pgtable_arm_mali_lpae_init_fns,
+ [ARM_ADRENO_GPU_LPAE] = &io_pgtable_arm_adreno_gpu_lpae_init_fns,
#endif
#ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S
[ARM_V7S] = &io_pgtable_arm_v7s_init_fns,
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index b5a450a..4871e85 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -13,6 +13,7 @@ enum io_pgtable_fmt {
ARM_64_LPAE_S2,
ARM_V7S,
ARM_MALI_LPAE,
+ ARM_ADRENO_GPU_LPAE,
IO_PGTABLE_NUM_FMTS,
};
@@ -213,5 +214,6 @@ extern struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns;
extern struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns;
extern struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns;
extern struct io_pgtable_init_fns io_pgtable_arm_mali_lpae_init_fns;
+extern struct io_pgtable_init_fns io_pgtable_arm_adreno_gpu_lpae_init_fns;
#endif /* __IO_PGTABLE_H */
--
2.7.4
_______________________________________________
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 v3 0/2] iommu/arm-smmu: Split pagetable support
From: Jordan Crouse @ 2019-08-07 22:19 UTC (permalink / raw)
To: freedreno
Cc: Rob Herring, Will Deacon, jean-philippe.brucker, linux-arm-msm,
Joerg Roedel, linux-kernel, iommu, Zhen Lei, robin.murphy,
linux-arm-kernel
This is part of an ongoing evolution for enabling split pagetable support for
arm-smmu. Previous versions can be found [1].
In the discussion for v2 Robin pointed out that this is a very Adreno specific
use case and that is exactly true. Not only do we want to configure and use a
pagetable in the TTBR1 space, we also want to configure the TTBR0 region but
not allocate a pagetable for it or touch it until the GPU hardware does so. As
much as I want it to be a generic concept it really isn't.
This revision leans into that idea. Most of the same io-pgtable code is there
but now it is wrapped as an Adreno GPU specific format that is selected by the
compatible string in the arm-smmu device.
Additionally, per Robin's suggestion we are skipping creating a TTBR0 pagetable
to save on wasted memory.
This isn't as clean as I would like it to be but I think that this is a better
direction than trying to pretend that the generic format would work.
I'm tempting fate by posting this and then taking some time off, but I wanted
to try to kick off a conversation or at least get some flames so I can try to
refine this again next week. Please take a look and give some advice on the
direction.
[1] https://patchwork.freedesktop.org/series/63403/
Jordan
Jordan Crouse (2):
iommu/io-pgtable-arm: Add support for ARM_ADRENO_GPU_LPAE io-pgtable
format
iommu/arm-smmu: Add support for Adreno GPU pagetable formats
drivers/iommu/arm-smmu.c | 8 +-
drivers/iommu/io-pgtable-arm.c | 214 ++++++++++++++++++++++++++++++++++++++---
drivers/iommu/io-pgtable.c | 1 +
include/linux/io-pgtable.h | 2 +
4 files changed, 209 insertions(+), 16 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [nomadik:ux500-skomer 5/7] main.c:undefined reference to `printascii'
From: kbuild test robot @ 2019-08-07 21:48 UTC (permalink / raw)
To: Linus Walleij; +Cc: kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-skomer
head: 7357fee56d5c76b95d19fbc0a7b08d0195b4846a
commit: be5f70b7d789ba870acbf1068e42a78e4a279d40 [5/7] uglyhack printascii
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout be5f70b7d789ba870acbf1068e42a78e4a279d40
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
init/main.o: In function `start_kernel':
>> main.c:(.init.text+0x71c): undefined reference to `printascii'
kernel/printk/printk.o: In function `vprintk_store':
>> printk.c:(.text+0x2fc0): undefined reference to `printascii'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 48009 bytes --]
[-- Attachment #3: 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
* Offer
From: Charlotte Davis @ 2019-08-07 21:22 UTC (permalink / raw)
To: linux-arm-kernel
An offer to work within your region for a decent salary without
affecting your present job.
_______________________________________________
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] clk: aspeed: Add SDIO gate
From: Stephen Boyd @ 2019-08-07 21:15 UTC (permalink / raw)
To: Andrew Jeffery, linux-clk
Cc: linux-aspeed, Andrew Jeffery, mturquette, ryanchen.aspeed,
linux-kernel, Joel Stanley, linux-arm-kernel
In-Reply-To: <20190710141009.20651-1-andrew@aj.id.au>
Quoting Andrew Jeffery (2019-07-10 07:10:09)
> From: Joel Stanley <joel@jms.id.au>
>
> The clock divisor comes with an enable bit (gate). This was not
> implemented as we didn't have access to SD hardware when writing the
> driver. Now that we can test it, add the gate as a parent to the
> divisor.
>
> There is no reason to expose the gate separately, so users will enable
> it by turning on the ASPEED_CLK_SDIO divisor.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> [aj: Minor style cleanup]
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
Applied to clk-next
_______________________________________________
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] phy-rockchip-inno-hdmi: Fix RK3328_TERM_RESISTOR_CALIB_SPEED_7_0's third value
From: Heiko Stübner @ 2019-08-07 21:02 UTC (permalink / raw)
To: Nathan Chancellor, Kishon Vijay Abraham I
Cc: kernelci . org bot, Andrzej Hajda, Naresh Kamboju, linux-kernel,
linux-rockchip, linux-arm-kernel, Robin Murphy, Guenter Roeck
In-Reply-To: <20190807192305.6604-1-natechancellor@gmail.com>
Am Mittwoch, 7. August 2019, 21:23:05 CEST schrieb Nathan Chancellor:
> After commit "linux/bits.h: Add compile time sanity check of GENMASK
> inputs" [1], arm64 defconfig builds started failing:
>
> In file included from ../include/linux/bits.h:22,
> from ../include/linux/bitops.h:5,
> from ../include/linux/kernel.h:12,
> from ../include/linux/clk.h:13,
> from ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:9:
> ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c: In function 'inno_hdmi_phy_rk3328_power_on':
> ../include/linux/build_bug.h:16:45: error: negative width in bit-field '<anonymous>'
> 16 | #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
> | ^
> ../include/linux/bits.h:24:18: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
> 24 | ((unsigned long)BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> | ^~~~~~~~~~~~~~~~~
> ../include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
> 39 | (GENMASK_INPUT_CHECK(high, low) + __GENMASK(high, low))
> | ^~~~~~~~~~~~~~~~~~~
> ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:24:42: note: in expansion of macro 'GENMASK'
> 24 | #define UPDATE(x, h, l) (((x) << (l)) & GENMASK((h), (l)))
> | ^~~~~~~
> ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:201:50: note: in expansion of macro 'UPDATE'
> 201 | #define RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(x) UPDATE(x, 7, 9)
> | ^~~~~~
> ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:1046:26: note: in expansion of macro 'RK3328_TERM_RESISTOR_CALIB_SPEED_7_0'
> 1046 | inno_write(inno, 0xc6, RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(v));
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> As pointed out by Robin and Guenter, inno_write's val argument is an
> 8-bit value so having a mask larger than that doesn't make sense. This
> also matches the rest of the *_7_0 macros in this driver.
>
> [1]: https://lore.kernel.org/lkml/20190801230358.4193-2-rikard.falkeborn@gmail.com/
>
> Reported-by: Andrzej Hajda <a.hajda@samsung.com>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Reported-by: kernelci.org bot <bot@kernelci.org>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Suggested-by: Guenter Roeck <linux@roeck-us.net>
> Suggested-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
on a rk3328-rock64 hdmi output still works
Tested-by: Heiko Stuebner <heiko@sntech.de>
@Kishon: Would probably be good to get this fast into 5.3-rc.
Heiko
> drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
> index b10a84cab4a7..2b97fb1185a0 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
> @@ -198,7 +198,7 @@
> #define RK3328_BYPASS_TERM_RESISTOR_CALIB BIT(7)
> #define RK3328_TERM_RESISTOR_CALIB_SPEED_14_8(x) UPDATE((x) >> 8, 6, 0)
> /* REG:0xc6 */
> -#define RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(x) UPDATE(x, 7, 9)
> +#define RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(x) UPDATE(x, 7, 0)
> /* REG:0xc7 */
> #define RK3328_TERM_RESISTOR_50 UPDATE(0, 2, 1)
> #define RK3328_TERM_RESISTOR_62_5 UPDATE(1, 2, 1)
>
_______________________________________________
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 v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Dave Hansen @ 2019-08-07 20:38 UTC (permalink / raw)
To: Catalin Marinas, linux-arm-kernel
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Will Deacon, Vincenzo Frascino
In-Reply-To: <20190807155321.9648-2-catalin.marinas@arm.com>
On 8/7/19 8:53 AM, Catalin Marinas wrote:
> +- mmap() done by the process itself (or its parent), where either:
> +
> + - flags have the **MAP_ANONYMOUS** bit set
> + - the file descriptor refers to a regular file (including those returned
> + by memfd_create()) or **/dev/zero**
What's a "regular file"? ;)
> +- brk() system call done by the process itself (i.e. the heap area between
> + the initial location of the program break at process creation and its
> + current location).
> +
> +- any memory mapped by the kernel in the address space of the process
> + during creation and with the same restrictions as for mmap() above (e.g.
> + data, bss, stack).
> +
> +The AArch64 Tagged Address ABI is an opt-in feature and an application can
> +control it via **prctl()** as follows:
> +
> +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address
> + ABI for the calling process.
> +
> + The (unsigned int) arg2 argument is a bit mask describing the control mode
> + used:
> +
> + - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default
> + status is disabled.
> +
> + The arguments arg3, arg4, and arg5 are ignored.
For previous prctl()'s, we've found that it's best to require that the
unused arguments be 0. Without that, apps are free to put garbage
there, which makes extending the prctl to use other arguments impossible
in the future.
Also, shouldn't this be converted over to an arch_prctl()?
> +The prctl(PR_SET_TAGGED_ADDR_CTRL, ...) will return -EINVAL if the
> +AArch64 Tagged Address ABI is not available
> +(CONFIG_ARM64_TAGGED_ADDR_ABI disabled or sysctl abi.tagged_addr=0).
> +
> +The ABI properties set by the mechanism described above are inherited by
> +threads of the same application and fork()'ed children but cleared by
> +execve().
What is the scope of these prctl()'s? Are they thread-scoped or
process-scoped? Can two threads in the same process run with different
tagging ABI modes?
> +Opting in (the prctl() option described above only) to or out of the
> +AArch64 Tagged Address ABI can be disabled globally at runtime using the
> +sysctl interface:
> +
> +- **abi.tagged_addr**: a new sysctl interface that can be used to prevent
> + applications from enabling or disabling the relaxed ABI. The sysctl
> + supports the following configuration options:
> +
> + - **0**: disable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to
> + enable/disable the AArch64 Tagged Address ABI globally
> +
> + - **1** (Default): enable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to
> + enable/disable the AArch64 Tagged Address ABI globally
> +
> + Note that this sysctl does not affect the status of the AArch64 Tagged
> + Address ABI of the running processes.
Shouldn't the name be "abi.tagged_addr_control" or something? It
actually has *zero* direct effect on tagged addresses in the ABI.
What's the reason for allowing it to be toggled at runtime like this?
Wouldn't it make more sense to just have it be a boot option so you
*know* what the state of individual processes is?
> +When a process has successfully enabled the new ABI by invoking
> +prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE), the following
> +behaviours are guaranteed:
> +
> +- Every currently available syscall, except the cases mentioned in section
> + 3, can accept any valid tagged pointer. The same rule is applicable to
> + any syscall introduced in the future.
> +
> +- The syscall behaviour is undefined for non valid tagged pointers.
Do you really mean "undefined"? I mean, a bad pointer is a bad pointer.
Why should it matter if it's a tagged bad pointer or an untagged bad
pointer?
...
> +A definition of the meaning of tagged pointers on AArch64 can be found in:
> +Documentation/arm64/tagged-pointers.txt.
> +
> +3. AArch64 Tagged Address ABI Exceptions
> +-----------------------------------------
> +
> +The behaviour described in section 2, with particular reference to the
> +acceptance by the syscalls of any valid tagged pointer, is not applicable
> +to the following cases:
This is saying things in a pretty roundabout manner. Can't it just say:
"The following cases do not accept tagged pointers:"
> +- mmap() addr parameter.
> +
> +- mremap() new_address parameter.
Is munmap() missing? Or was there a reason for leaving it out?
> +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
> + PR_SET_MM_MAP_SIZE.
> +
> +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
> +
> +Any attempt to use non-zero tagged pointers will lead to undefined
> +behaviour.
I wonder if you want to generalize this a bit. I think you're saying
that parts of the ABI that modify the *layout* of the address space
never accept tagged pointers.
> +4. Example of correct usage
> +---------------------------
> +.. code-block:: c
> +
> + void main(void)
> + {
> + static int tbi_enabled = 0;
> + unsigned long tag = 0;
> +
> + char *ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
> + MAP_ANONYMOUS, -1, 0);
> +
> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE,
> + 0, 0, 0) == 0)
> + tbi_enabled = 1;
> +
> + if (ptr == (void *)-1) /* MAP_FAILED */
> + return -1;
> +
> + if (tbi_enabled)
> + tag = rand() & 0xff;
> +
> + ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
> +
> + *ptr = 'a';
> +
> + ...
> + }
It looks like the TAG_SHIFT and tag size are pretty baked into the
aarch64 architecture. But, are you confident that no future
implementations will want different positions or sizes? (obviously
controlled by other TCR_EL1 bits)
_______________________________________________
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 v10 20/22] x86: mm: Convert dump_pagetables to use walk_page_range
From: Andrew Morton @ 2019-08-07 20:16 UTC (permalink / raw)
To: Steven Price
Cc: Mark Rutland, Dave Hansen, Arnd Bergmann, Ard Biesheuvel,
Peter Zijlstra, Catalin Marinas, x86, linux-kernel, linux-mm,
Jérôme Glisse, Ingo Molnar, Borislav Petkov,
Kirill A. Shutemov, Andy Lutomirski, H. Peter Anvin, James Morse,
Thomas Gleixner, Will Deacon, linux-arm-kernel, Liang, Kan
In-Reply-To: <066fa4ca-5a46-ba86-607f-9c3e16f79cde@arm.com>
On Wed, 7 Aug 2019 13:58:21 +0100 Steven Price <steven.price@arm.com> wrote:
> > ./arch/x86/include/asm/pgtable_64_types.h:56:22: error: initializer element is not constant
> > #define PTRS_PER_PGD 512
> > ^
>
> This is very unhelpful of GCC - it's actually PTRS_PER_P4D which isn't
> constant!
Well. You had every right to assume that an all-caps macro is a
compile-time constant.
We are innocent victims of Kirill's c65e774fb3f6af2 ("x86/mm: Make
PGDIR_SHIFT and PTRS_PER_P4D variable") which lazily converted these
macros into runtime-only, under some Kconfig settings. It should have
changed those macros into static inlined lower-case functions.
_______________________________________________
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 v2] tracing/arm64: Have max stack tracer handle the case of return address after data
From: Steven Rostedt @ 2019-08-07 19:29 UTC (permalink / raw)
To: linux-kernel
Cc: Jiping Ma, Mark Rutland, catalin.marinas, will.deacon, mingo,
Joel Fernandes, linux-arm-kernel
In-Reply-To: <20190807172907.155165959@goodmis.org>
[ I should have added Mark as Cc ]
Dear ARM64 folks,
Are you OK with this patch set?
If so, please ACK.
Should it be marked for stable?
Hmm, I'm starting to think not.
-- Steve
On Wed, 07 Aug 2019 13:28:27 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
>
> Most archs (well at least x86) store the function call return address on the
> stack before storing the local variables for the function. The max stack
> tracer depends on this in its algorithm to display the stack size of each
> function it finds in the back trace.
>
> Some archs (arm64), may store the return address (from its link register)
> just before calling a nested function. There's no reason to save the link
> register on leaf functions, as it wont be updated. This breaks the algorithm
> of the max stack tracer.
>
> Add a new define ARCH_RET_ADDR_AFTER_LOCAL_VARS that an architecture may set
> if it stores the return address (link register) after it stores the
> function's local variables, and have the stack trace shift the values of the
> mapped stack size to the appropriate functions.
>
> Link: 20190802094103.163576-1-jiping.ma2@windriver.com
>
> Reported-by: Jiping Ma <jiping.ma2@windriver.com>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
> arch/arm64/include/asm/ftrace.h | 13 +++++++++++++
> kernel/trace/trace_stack.c | 14 ++++++++++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
> index 5ab5200b2bdc..961e98618db4 100644
> --- a/arch/arm64/include/asm/ftrace.h
> +++ b/arch/arm64/include/asm/ftrace.h
> @@ -14,6 +14,19 @@
> #define MCOUNT_ADDR ((unsigned long)_mcount)
> #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE
>
> +/*
> + * Currently, gcc tends to save the link register after the local variables
> + * on the stack. This causes the max stack tracer to report the function
> + * frame sizes for the wrong functions. By defining
> + * ARCH_RET_ADDR_AFTER_LOCAL_VARS, it will tell the stack tracer to expect
> + * to find the return address on the stack after the local variables have
> + * been set up.
> + *
> + * Note, this may change in the future, and we will need to deal with that
> + * if it were to happen.
> + */
> +#define ARCH_RET_ADDR_AFTER_LOCAL_VARS 1
> +
> #ifndef __ASSEMBLY__
> #include <linux/compat.h>
>
> diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
> index 5d16f73898db..40e4a88eea8f 100644
> --- a/kernel/trace/trace_stack.c
> +++ b/kernel/trace/trace_stack.c
> @@ -158,6 +158,20 @@ static void check_stack(unsigned long ip, unsigned long *stack)
> i++;
> }
>
> +#ifdef ARCH_RET_ADDR_AFTER_LOCAL_VARS
> + /*
> + * Some archs will store the link register before calling
> + * nested functions. This means the saved return address
> + * comes after the local storage, and we need to shift
> + * for that.
> + */
> + if (x > 1) {
> + memmove(&stack_trace_index[0], &stack_trace_index[1],
> + sizeof(stack_trace_index[0]) * (x - 1));
> + x--;
> + }
> +#endif
> +
> stack_trace_nr_entries = x;
>
> if (task_stack_end_corrupted(current)) {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH 00/10] ARM: davinci: use the new clocksource driver
From: Sekhar Nori @ 2019-08-07 19:28 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman
Cc: Bartosz Golaszewski, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <CAMRc=Mes8dEwscGU8LLQ5CcxmUnhBwt2iP0wk1qNRjRwy8CcFA@mail.gmail.com>
On 05/08/19 1:59 PM, Bartosz Golaszewski wrote:
> pon., 22 lip 2019 o 15:17 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>>
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> Sekhar,
>>
>> the following patches switch DaVinci to using the new clocksource driver which
>> is now upstream. They are rebased on top of v5.3-rc1. Additionally the
>> following two patches were reverted locally due to a regression in v5.3-rc1
>> about which the relevant maintainers have been already notified:
>>
>> 2eef1399a866 modules: fix BUG when load module with rodata=n
>> 93651f80dcb6 modules: fix compile error if don't have strict module rwx
>>
>> Bartosz Golaszewski (10):
>> ARM: davinci: enable the clocksource driver for DT mode
>> ARM: davinci: WARN_ON() if clk_get() fails
>> ARM: davinci: da850: switch to using the clocksource driver
>> ARM: davinci: da830: switch to using the clocksource driver
>> ARM: davinci: move timer definitions to davinci.h
>> ARM: davinci: dm355: switch to using the clocksource driver
>> ARM: davinci: dm365: switch to using the clocksource driver
>> ARM: davinci: dm644x: switch to using the clocksource driver
>> ARM: davinci: dm646x: switch to using the clocksource driver
>> ARM: davinci: remove legacy timer support
>>
>> arch/arm/Kconfig | 1 +
>> arch/arm/mach-davinci/Makefile | 3 +-
>> arch/arm/mach-davinci/da830.c | 45 +--
>> arch/arm/mach-davinci/da850.c | 50 +--
>> arch/arm/mach-davinci/davinci.h | 3 +
>> arch/arm/mach-davinci/devices-da8xx.c | 1 -
>> arch/arm/mach-davinci/devices.c | 19 -
>> arch/arm/mach-davinci/dm355.c | 28 +-
>> arch/arm/mach-davinci/dm365.c | 26 +-
>> arch/arm/mach-davinci/dm644x.c | 28 +-
>> arch/arm/mach-davinci/dm646x.c | 28 +-
>> arch/arm/mach-davinci/include/mach/common.h | 17 -
>> arch/arm/mach-davinci/include/mach/time.h | 35 --
>> arch/arm/mach-davinci/time.c | 414 --------------------
>> 14 files changed, 110 insertions(+), 588 deletions(-)
>> delete mode 100644 arch/arm/mach-davinci/include/mach/time.h
>> delete mode 100644 arch/arm/mach-davinci/time.c
>>
>> --
>> 2.21.0
>>
>
> Hi Sekhar,
>
> a gentle ping. Is this series good to go in for v5.4?
Hi Bartosz, a quick test shows that DM365 fails to boot after this. Can
you please see if there is anything obviously wrong for that SoC. Rest
seems to be okay.
Thanks,
Sekhar
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] phy-rockchip-inno-hdmi: Fix RK3328_TERM_RESISTOR_CALIB_SPEED_7_0's third value
From: Nathan Chancellor @ 2019-08-07 19:23 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Heiko Stuebner
Cc: kernelci . org bot, Andrzej Hajda, Naresh Kamboju, linux-kernel,
linux-rockchip, linux-arm-kernel, Nathan Chancellor, Robin Murphy,
Guenter Roeck
After commit "linux/bits.h: Add compile time sanity check of GENMASK
inputs" [1], arm64 defconfig builds started failing:
In file included from ../include/linux/bits.h:22,
from ../include/linux/bitops.h:5,
from ../include/linux/kernel.h:12,
from ../include/linux/clk.h:13,
from ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:9:
../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c: In function 'inno_hdmi_phy_rk3328_power_on':
../include/linux/build_bug.h:16:45: error: negative width in bit-field '<anonymous>'
16 | #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
| ^
../include/linux/bits.h:24:18: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
24 | ((unsigned long)BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
| ^~~~~~~~~~~~~~~~~
../include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
39 | (GENMASK_INPUT_CHECK(high, low) + __GENMASK(high, low))
| ^~~~~~~~~~~~~~~~~~~
../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:24:42: note: in expansion of macro 'GENMASK'
24 | #define UPDATE(x, h, l) (((x) << (l)) & GENMASK((h), (l)))
| ^~~~~~~
../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:201:50: note: in expansion of macro 'UPDATE'
201 | #define RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(x) UPDATE(x, 7, 9)
| ^~~~~~
../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:1046:26: note: in expansion of macro 'RK3328_TERM_RESISTOR_CALIB_SPEED_7_0'
1046 | inno_write(inno, 0xc6, RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(v));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As pointed out by Robin and Guenter, inno_write's val argument is an
8-bit value so having a mask larger than that doesn't make sense. This
also matches the rest of the *_7_0 macros in this driver.
[1]: https://lore.kernel.org/lkml/20190801230358.4193-2-rikard.falkeborn@gmail.com/
Reported-by: Andrzej Hajda <a.hajda@samsung.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index b10a84cab4a7..2b97fb1185a0 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -198,7 +198,7 @@
#define RK3328_BYPASS_TERM_RESISTOR_CALIB BIT(7)
#define RK3328_TERM_RESISTOR_CALIB_SPEED_14_8(x) UPDATE((x) >> 8, 6, 0)
/* REG:0xc6 */
-#define RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(x) UPDATE(x, 7, 9)
+#define RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(x) UPDATE(x, 7, 0)
/* REG:0xc7 */
#define RK3328_TERM_RESISTOR_50 UPDATE(0, 2, 1)
#define RK3328_TERM_RESISTOR_62_5 UPDATE(1, 2, 1)
--
2.23.0.rc1
_______________________________________________
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: [RESEND][PATCH] usb: musb: sunxi: propagate devicetree node to glue pdev
From: Bin Liu @ 2019-08-07 18:57 UTC (permalink / raw)
To: Mans Rullgard
Cc: Maxime Ripard, Greg Kroah-Hartman, linux-usb, linux-kernel,
Chen-Yu Tsai, linux-arm-kernel
In-Reply-To: <20190806113458.3304-1-mans@mansr.com>
On Tue, Aug 06, 2019 at 12:34:58PM +0100, Mans Rullgard wrote:
> In order for devicetree nodes to be correctly associated with attached
> devices, the controller node needs to be propagated to the glue device.
>
> Signed-off-by: Mans Rullgard <mans@mansr.com>
Applied. Thanks.
-Bin.
_______________________________________________
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] kernfs: fix memleak in kernel_ops_readdir()
From: Tejun Heo @ 2019-08-07 18:45 UTC (permalink / raw)
To: Tony Lindgren, Greg Kroah-Hartman
Cc: Andrea Arcangeli, Russell King, linux-omap, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190807132928.GD5443@atomide.com>
Hello,
On Wed, Aug 07, 2019 at 06:29:28AM -0700, Tony Lindgren wrote:
> Hi,
>
> * Tejun Heo <tj@kernel.org> [691231 23:00]:
> > From: Andrea Arcangeli <aarcange@redhat.com>
> >
> > If getdents64 is killed or hits on segfault, it'll leave cgroups
> > directories in sysfs pinned leaking memory because the kernfs node
> > won't be freed on rmdir and the parent neither.
>
> Somehow this causes a regression in Linux next for me where I'm seeing
> lots of sysfs entries now missing under /sys/bus/platform/devices.
>
> For example, I now only see one .serial entry show up in sysfs.
> Things work again if I revert commit cc798c83898e ("kernfs: fix memleak
> inkernel_ops_readdir()"). Any ideas why that would be?
>
> Below is a diff -u of ls /sys/bus/platform/devices for reference
> showing the missing entries with cc798c83898e.
Ugh, you're right. It can get double-put cuz ctx->pos is put by
release too. Greg, sorry about the noise but can you please revert
the patch? I'll look into why this looked like memory leak from
slabinfo side.
Thanks.
--
tejun
_______________________________________________
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 6/6] PSCI: cpuidle: Refactor CPU suspend power_state parameter handling
From: Daniel Lezcano @ 2019-08-07 18:09 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pm
Cc: Mark Rutland, Ulf Hansson, Catalin Marinas, Rafael J. Wysocki,
LKML, Sudeep Holla, Will Deacon, LAKML
In-Reply-To: <20190722153745.32446-7-lorenzo.pieralisi@arm.com>
On 22/07/2019 17:37, Lorenzo Pieralisi wrote:
> Current PSCI code handles idle state entry through the
> psci_cpu_suspend_enter() API, that takes an idle state index as a
> parameter and convert the index into a previously initialized
> power_state parameter before calling the PSCI.CPU_SUSPEND() with it.
>
> This is unwieldly, since it forces the PSCI firmware layer to keep track
> of power_state parameter for every idle state so that the
> index->power_state conversion can be made in the PSCI firmware layer
> instead of the CPUidle driver implementations.
>
> Move the power_state handling out of drivers/firmware/psci
> into the respective ACPI/DT PSCI CPUidle backends and convert
> the psci_cpu_suspend_enter() API to get the power_state
> parameter as input, which makes it closer to its firmware
> interface PSCI.CPU_SUSPEND() API.
>
> A notable side effect is that the PSCI ACPI/DT CPUidle backends
> now can directly handle (and if needed update) power_state
> parameters before handing them over to the PSCI firmware
> interface to trigger PSCI.CPU_SUSPEND() calls.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
AFAICT,
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
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] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Alex Deucher @ 2019-08-07 18:00 UTC (permalink / raw)
To: Koenig, Christian
Cc: kernel-build-reports@lists.linaro.org, Zhou1, Tao,
amd-gfx@lists.freedesktop.org, Li, Dennis, Christoph Hellwig,
broonie@kernel.org, linux-next@vger.kernel.org,
Deucher, Alexander, akpm@linux-foundation.org,
linux-arm-kernel@lists.infradead.org, Zhang, Hawking
In-Reply-To: <c613ca25-4443-f275-ea8d-6d55af10ac77@amd.com>
On Wed, Aug 7, 2019 at 9:03 AM Koenig, Christian
<Christian.Koenig@amd.com> wrote:
>
> Am 07.08.19 um 15:00 schrieb Christoph Hellwig:
> > On Wed, Aug 07, 2019 at 10:55:01AM +0000, Koenig, Christian wrote:
> >>>> Essentially writeq/readq doesn't seems to be available on all
> >>>> architectures either.
> >>> writeq/readq are provided whenever the CPU actually supports 64-bit
> >>> atomic loads and stores.
> >> Is there a config option which we can make the driver depend on?
> >>
> >> I mean that ARM doesn't support 64bit atomic loads and stores on MMIO is
> >> quite a boomer for us.
> > The model is to cheack if readq/writeq are defined, and if not to
> > include the one of io-64-nonatomic-hi-lo.h or io-64-nonatomic-lo-hi.h.
> > The reason for that is that hardware is supposed to be able to deal with
> > two 32-bit writes, but it depends on the hardware if the lower or upper
> > half is what commits the write.
>
> Read, but as I understood Tao change this is not the case here.
> Otherwise we would just use our WREG32/RREG32 macros in the driver.
>
> Tao, please explain why exactly we need the WREG64/RREG64 change which
> caused this.
We use this for doorbells as well which is also MMIO. Basically we
have the requirement to read or write the full 64 bits in one
operation. E.g., for 64-bit doorbells, the entire register is the
trigger so if we do it as two writes, we'll miss half the update. In
the case of some error counter registers, reading the register will
clear the value so we need to read out the full value or we lose the
half the value. This works properly on x86 and AMD64.
Alex
>
> Christian.
>
> >
> > The only 32-bit platform that claims support for readq/writeq is sh,
> > and I have doubts if that actually works as expected.
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFCv2 9/9] dt-bindings: watchdog: meson-gxbb-wdt: convert to yaml
From: Guenter Roeck @ 2019-08-07 17:59 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, robh+dt, linux-watchdog, linux-arm-kernel,
devicetree
In-Reply-To: <20190805120320.32282-10-narmstrong@baylibre.com>
On Mon, Aug 05, 2019 at 02:03:20PM +0200, Neil Armstrong wrote:
> Now that we have the DT validation in place, let's convert the device tree
> bindings for the Amlogic GXBB Watchdog timer over to a YAML schemas.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> .../watchdog/amlogic,meson-gxbb-wdt.yaml | 37 +++++++++++++++++++
> .../bindings/watchdog/meson-gxbb-wdt.txt | 16 --------
> 2 files changed, 37 insertions(+), 16 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
> delete mode 100644 Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
> new file mode 100644
> index 000000000000..d7352f709b37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 BayLibre, SAS
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/watchdog/amlogic,meson-gxbb-wdt.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Meson GXBB SoCs Watchdog timer
> +
> +maintainers:
> + - Neil Armstrong <narmstrong@baylibre.com>
> +
> +properties:
> + compatible:
> + enum:
> + - amlogic,meson-gxbb-wdt
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> + description:
> + A phandle to the clock of this PHY
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +examples:
> + - |
> + watchdog@98d0 {
> + compatible = "amlogic,meson-gxbb-wdt";
> + reg = <0x98d0 0x10>;
> + clocks = <&xtal>;
> + };
> diff --git a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt b/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
> deleted file mode 100644
> index c7fe36fa739c..000000000000
> --- a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -Meson GXBB SoCs Watchdog timer
> -
> -Required properties:
> -
> -- compatible : should be "amlogic,meson-gxbb-wdt"
> -- reg : Specifies base physical address and size of the registers.
> -- clocks : Should be a phandle to the Watchdog clock source, for GXBB the xtal
> - is the default clock source.
> -
> -Example:
> -
> -wdt: watchdog@98d0 {
> - compatible = "amlogic,meson-gxbb-wdt";
> - reg = <0 0x98d0 0x0 0x10>;
> - clocks = <&xtal>;
> -};
_______________________________________________
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 v8 00/14] Rockchip ISP1 Driver
From: Helen Koike @ 2019-08-07 17:57 UTC (permalink / raw)
To: Sakari Ailus
Cc: devicetree, eddie.cai.linux, kernel, heiko, jacob2.chen,
jeffy.chen, zyc, linux-kernel, tfiga, linux-rockchip,
hans.verkuil, laurent.pinchart, zhengsq, mchehab, ezequiel,
linux-arm-kernel, linux-media
In-Reply-To: <20190807153759.GP21370@paasikivi.fi.intel.com>
On 8/7/19 12:37 PM, Sakari Ailus wrote:
> On Tue, Jul 30, 2019 at 03:42:42PM -0300, Helen Koike wrote:
>> Hello,
>>
>> I'm re-sending a new version of ISP(Camera) v4l2 driver for rockchip
>> rk3399 SoC.
>>
>> I didn't change much from the last version, just applying the
>> suggestions made in the previous one.
>>
>> This patchset is also available at:
>> https://gitlab.collabora.com/koike/linux/tree/rockchip/isp/v8
>>
>> Libcamera patched to work with this version:
>> https://gitlab.collabora.com/koike/libcamera
>> (also sent to the mailing list)
>>
>> I tested on the rockpi 4 with a rpi v1.3 sensor and also with the
>> Scarlet Chromebook.
>
> Could you also post media-ctl -p printout e.g. as a reply to the cover
> letter?
>
> Thanks.
>
Yes, I had posted in v7 and I forgot to add it in subsequent cover letters:
media-ctl --print-dot -> file available at: http://ix.io/1NIH
root@rockpi:~# media-ctl -p
Media controller API version 5.3.0
Media device information
------------------------
driver rkisp1
model rkisp1
serial
bus info platform: rkisp1
hw revision 0x0
driver version 5.3.0
Device topology
- entity 1: rkisp1-isp-subdev (4 pads, 5 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
[fmt:SBGGR10_1X10/800x600 field:none
crop.bounds:(0,0)/800x600
crop:(0,0)/800x600]
<- "ov5647 4-0036":0 [ENABLED]
pad1: Sink
[fmt:FIXED/800x600 field:none]
<- "rkisp1-input-params":0 [ENABLED]
pad2: Source
[fmt:YUYV8_2X8/800x600 field:none
crop.bounds:(0,0)/800x600
crop:(0,0)/800x600]
-> "rkisp1_selfpath":0 [ENABLED]
-> "rkisp1_mainpath":0 [ENABLED]
pad3: Source
[fmt:FIXED/800x600 field:none]
-> "rkisp1-statistics":0 [ENABLED]
- entity 6: rkisp1_mainpath (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "rkisp1-isp-subdev":2 [ENABLED]
- entity 10: rkisp1_selfpath (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Sink
<- "rkisp1-isp-subdev":2 [ENABLED]
- entity 14: rkisp1-statistics (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video2
pad0: Sink
<- "rkisp1-isp-subdev":3 [ENABLED]
- entity 18: rkisp1-input-params (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video3
pad0: Source
-> "rkisp1-isp-subdev":1 [ENABLED]
- entity 22: ov5647 4-0036 (1 pad, 1 link)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev1
pad0: Source
[fmt:SBGGR8_1X8/1280x960 field:none]
-> "rkisp1-isp-subdev":0 [ENABLED]
Thanks
Helen
_______________________________________________
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 3/5] dt-bindings: arm: Extend SCMI to support new reset protocol
From: Sudeep Holla @ 2019-08-07 17:41 UTC (permalink / raw)
To: linux-arm-kernel, Rob Herring
Cc: Mark Rutland, devicetree, Peng Fan, Etienne Carriere,
Souvik Chakravarty, Philipp Zabel, wesleys, aidapala,
linux-kernel, Rob Herring, Saeed Nowshadi, Bo Zhang, Felix Burton,
Jim Quinlan, pajay, Gaku Inami, Volodymyr Babchuk
In-Reply-To: <20190806170208.6787-4-sudeep.holla@arm.com>
Hi Rob,
On Tue, Aug 06, 2019 at 06:02:06PM +0100, Sudeep Holla wrote:
> SCMIv2.0 adds a new Reset Management Protocol to manage various reset
> states a given device or domain can enter. Extend the existing SCMI
> bindings to add reset protocol support by re-using the reset bindings
> for bothe reset providers and consumers.
>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh+dt@kernel.org>
Sorry for the nag, can you review the binding so that I can plan
to get this merged for v5.4
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master boot: 263 boots: 11 failed, 186 passed with 64 offline, 1 untried/unknown, 1 conflict (next-20190802)
From: Mark Brown @ 2019-08-07 17:38 UTC (permalink / raw)
To: Andy Gross, khilman, Rob Clark, Sean Paul
Cc: kernel-build-reports, linux-arm-msm, dri-devel, linux-next,
freedreno, linux-arm-kernel
In-Reply-To: <5d4428ea.1c69fb81.4e1ae.1008@mx.google.com>
[-- Attachment #1.1: Type: text/plain, Size: 2287 bytes --]
On Fri, Aug 02, 2019 at 05:13:30AM -0700, kernelci.org bot wrote:
Today's -next still fails to boot on CM-QS600 with qcom_defconfig:
> qcom_defconfig:
> gcc-8:
> qcom-apq8064-cm-qs600: 1 failed lab
This has been going on since June. It crashes initializing the GPU:
[ 4.261135] adreno 4300000.adreno-3xx: 4300000.adreno-3xx supply vddcx not found, using dummy regulator
[ 4.270254] msm 5100000.mdp: [drm:msm_gpu_init] A320: using IOMMU
[ 4.280025] 8<--- cut here ---
[ 4.285557] Unable to handle kernel paging request at virtual address 40000000
[ 4.288430] pgd = (ptrval)
[ 4.295714] [40000000] *pgd=00000000
[ 4.298329] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[ 4.302054] Modules linked in:
[ 4.307352] CPU: 2 PID: 88 Comm: kworker/2:1 Tainted: G W 5.3.0-rc3-next-20190807 #1
[ 4.310391] Hardware name: Generic DT based system
[ 4.319353] Workqueue: events deferred_probe_work_func
[ 4.319930] usb 1-1: New USB device found, idVendor=04b4, idProduct=6570, bcdDevice=32.99
[ 4.324201] PC is at v7_dma_clean_range+0x1c/0x34
[ 4.324214] LR is at __dma_page_cpu_to_dev+0x28/0x8c
...
[ 4.753642] [] (v7_dma_clean_range) from [] (__dma_page_cpu_to_dev+0x28/0x8c)
[ 4.761795] [] (__dma_page_cpu_to_dev) from [] (arm_dma_sync_sg_for_device+0x4c/0x64)
[ 4.770654] [] (arm_dma_sync_sg_for_device) from [] (get_pages+0x1bc/0x218)
[ 4.780199] [] (get_pages) from [] (msm_gem_get_and_pin_iova+0xb4/0x13c)
[ 4.788704] [] (msm_gem_get_and_pin_iova) from [] (_msm_gem_kernel_new+0x38/0xa8)
[ 4.797386] [] (_msm_gem_kernel_new) from [] (msm_gem_kernel_new+0x24/0x2c)
[ 4.806501] [] (msm_gem_kernel_new) from [] (msm_gpu_init+0x4a4/0x614)
[ 4.815021] [] (msm_gpu_init) from [] (adreno_gpu_init+0x17c/0x288)
[ 4.823342] [] (adreno_gpu_init) from [] (a3xx_gpu_init+0x84/0x108)
[ 4.831239] [] (a3xx_gpu_init) from [] (adreno_bind+0x1c4/0x268)
[ 4.839224] [] (adreno_bind) from [] (component_bind_all+0x11c/0x258)
[ 4.847213] [] (component_bind_all) from [] (msm_drm_bind+0xf8/0x638)
[ 4.855282] [] (msm_drm_bind) from [] (try_to_bring_up_master+0x1fc/0x2b8)
More details including full logs and the image file at:
https://kernelci.org/boot/id/5d4ac1e659b514754b31b293/
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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
* [PATCH v2] firmware: arm_scmi: Use {get, put}_unaligned_le{32, 64} accessors
From: Sudeep Holla @ 2019-08-07 17:37 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-kernel, Philipp Zabel, Sudeep Holla
In-Reply-To: <20190807130038.26878-1-sudeep.holla@arm.com>
Instead of type-casting the {tx,rx}.buf all over the place while
accessing them to read/write __le{32,64} from/to the firmware, let's
use the existing {get,put}_unaligned_le{32,64} accessors to hide all
the type cast ugliness.
Suggested-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_scmi/base.c | 2 +-
drivers/firmware/arm_scmi/clock.c | 12 ++++--------
drivers/firmware/arm_scmi/common.h | 2 ++
drivers/firmware/arm_scmi/perf.c | 8 ++++----
drivers/firmware/arm_scmi/power.c | 6 +++---
drivers/firmware/arm_scmi/reset.c | 2 +-
drivers/firmware/arm_scmi/sensors.c | 17 ++++++-----------
7 files changed, 21 insertions(+), 28 deletions(-)
v1->v2:
- Dropped incorrect void ptr arithmetic and used unaligned_le64
accessors instead
diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
index 204390297f4b..f804e8af6521 100644
--- a/drivers/firmware/arm_scmi/base.c
+++ b/drivers/firmware/arm_scmi/base.c
@@ -204,7 +204,7 @@ static int scmi_base_discover_agent_get(const struct scmi_handle *handle,
if (ret)
return ret;
- *(__le32 *)t->tx.buf = cpu_to_le32(id);
+ put_unaligned_le32(id, t->tx.buf);
ret = scmi_do_xfer(handle, t);
if (!ret)
diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index 4a32ae1822a3..32526a793f3a 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -107,7 +107,7 @@ static int scmi_clock_attributes_get(const struct scmi_handle *handle,
if (ret)
return ret;
- *(__le32 *)t->tx.buf = cpu_to_le32(clk_id);
+ put_unaligned_le32(clk_id, t->tx.buf);
attr = t->rx.buf;
ret = scmi_do_xfer(handle, t);
@@ -204,15 +204,11 @@ scmi_clock_rate_get(const struct scmi_handle *handle, u32 clk_id, u64 *value)
if (ret)
return ret;
- *(__le32 *)t->tx.buf = cpu_to_le32(clk_id);
+ put_unaligned_le32(clk_id, t->tx.buf);
ret = scmi_do_xfer(handle, t);
- if (!ret) {
- __le32 *pval = t->rx.buf;
-
- *value = le32_to_cpu(*pval);
- *value |= (u64)le32_to_cpu(*(pval + 1)) << 32;
- }
+ if (!ret)
+ *value = get_unaligned_le64(t->rx.buf);
scmi_xfer_put(handle, t);
return ret;
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 43884e4ceac5..5237c2ff79fe 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -15,6 +15,8 @@
#include <linux/scmi_protocol.h>
#include <linux/types.h>
+#include <asm/unaligned.h>
+
#define PROTOCOL_REV_MINOR_MASK GENMASK(15, 0)
#define PROTOCOL_REV_MAJOR_MASK GENMASK(31, 16)
#define PROTOCOL_REV_MAJOR(x) (u16)(FIELD_GET(PROTOCOL_REV_MAJOR_MASK, (x)))
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index fb7f6cab2c11..9b338e66a24e 100644
--- a/drivers/firmware/arm_scmi/perf.c
+++ b/drivers/firmware/arm_scmi/perf.c
@@ -195,7 +195,7 @@ scmi_perf_domain_attributes_get(const struct scmi_handle *handle, u32 domain,
if (ret)
return ret;
- *(__le32 *)t->tx.buf = cpu_to_le32(domain);
+ put_unaligned_le32(domain, t->tx.buf);
attr = t->rx.buf;
ret = scmi_do_xfer(handle, t);
@@ -380,7 +380,7 @@ static int scmi_perf_mb_limits_get(const struct scmi_handle *handle, u32 domain,
if (ret)
return ret;
- *(__le32 *)t->tx.buf = cpu_to_le32(domain);
+ put_unaligned_le32(domain, t->tx.buf);
ret = scmi_do_xfer(handle, t);
if (!ret) {
@@ -459,11 +459,11 @@ static int scmi_perf_mb_level_get(const struct scmi_handle *handle, u32 domain,
return ret;
t->hdr.poll_completion = poll;
- *(__le32 *)t->tx.buf = cpu_to_le32(domain);
+ put_unaligned_le32(domain, t->tx.buf);
ret = scmi_do_xfer(handle, t);
if (!ret)
- *level = le32_to_cpu(*(__le32 *)t->rx.buf);
+ *level = get_unaligned_le32(t->rx.buf);
scmi_xfer_put(handle, t);
return ret;
diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
index 62f3401a1f01..5abef7079c0a 100644
--- a/drivers/firmware/arm_scmi/power.c
+++ b/drivers/firmware/arm_scmi/power.c
@@ -96,7 +96,7 @@ scmi_power_domain_attributes_get(const struct scmi_handle *handle, u32 domain,
if (ret)
return ret;
- *(__le32 *)t->tx.buf = cpu_to_le32(domain);
+ put_unaligned_le32(domain, t->tx.buf);
attr = t->rx.buf;
ret = scmi_do_xfer(handle, t);
@@ -147,11 +147,11 @@ scmi_power_state_get(const struct scmi_handle *handle, u32 domain, u32 *state)
if (ret)
return ret;
- *(__le32 *)t->tx.buf = cpu_to_le32(domain);
+ put_unaligned_le32(domain, t->tx.buf);
ret = scmi_do_xfer(handle, t);
if (!ret)
- *state = le32_to_cpu(*(__le32 *)t->rx.buf);
+ *state = get_unaligned_le32(t->rx.buf);
scmi_xfer_put(handle, t);
return ret;
diff --git a/drivers/firmware/arm_scmi/reset.c b/drivers/firmware/arm_scmi/reset.c
index 11cb8b5ccf34..c1d67a2af12f 100644
--- a/drivers/firmware/arm_scmi/reset.c
+++ b/drivers/firmware/arm_scmi/reset.c
@@ -88,7 +88,7 @@ scmi_reset_domain_attributes_get(const struct scmi_handle *handle, u32 domain,
if (ret)
return ret;
- *(__le32 *)t->tx.buf = cpu_to_le32(domain);
+ put_unaligned_le32(domain, t->tx.buf);
attr = t->rx.buf;
ret = scmi_do_xfer(handle, t);
diff --git a/drivers/firmware/arm_scmi/sensors.c b/drivers/firmware/arm_scmi/sensors.c
index 7570308a16a0..a400ea805fc2 100644
--- a/drivers/firmware/arm_scmi/sensors.c
+++ b/drivers/firmware/arm_scmi/sensors.c
@@ -120,7 +120,7 @@ static int scmi_sensor_description_get(const struct scmi_handle *handle,
do {
/* Set the number of sensors to be skipped/already read */
- *(__le32 *)t->tx.buf = cpu_to_le32(desc_index);
+ put_unaligned_le32(desc_index, t->tx.buf);
ret = scmi_do_xfer(handle, t);
if (ret)
@@ -217,7 +217,6 @@ static int scmi_sensor_reading_get(const struct scmi_handle *handle,
u32 sensor_id, u64 *value)
{
int ret;
- __le32 *pval;
struct scmi_xfer *t;
struct scmi_msg_sensor_reading_get *sensor;
struct sensors_info *si = handle->sensor_priv;
@@ -229,24 +228,20 @@ static int scmi_sensor_reading_get(const struct scmi_handle *handle,
if (ret)
return ret;
- pval = t->rx.buf;
sensor = t->tx.buf;
sensor->id = cpu_to_le32(sensor_id);
if (s->async) {
sensor->flags = cpu_to_le32(SENSOR_READ_ASYNC);
ret = scmi_do_xfer_with_response(handle, t);
- if (!ret) {
- *value = le32_to_cpu(*(pval + 1));
- *value |= (u64)le32_to_cpu(*(pval + 2)) << 32;
- }
+ if (!ret)
+ *value = get_unaligned_le64((void *)
+ ((__le32 *)t->rx.buf + 1));
} else {
sensor->flags = cpu_to_le32(0);
ret = scmi_do_xfer(handle, t);
- if (!ret) {
- *value = le32_to_cpu(*pval);
- *value |= (u64)le32_to_cpu(*(pval + 1)) << 32;
- }
+ if (!ret)
+ *value = get_unaligned_le64(t->rx.buf);
}
scmi_xfer_put(handle, t);
--
2.17.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
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Vasily Khoruzhick @ 2019-08-07 17:36 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Jared D . McNeill, Chen-Yu Tsai,
Rob Herring, Harald Geyer, Robin Murphy, arm-linux
In-Reply-To: <20190807115614.phm7sbyae6yajkug@flea>
On Wed, Aug 7, 2019 at 4:56 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Tue, Aug 06, 2019 at 07:39:26PM -0700, Vasily Khoruzhick wrote:
> > On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > >
> > > On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > > > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> > > >>
> > > >> Vasily Khoruzhick writes:
> > > >>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > >>>>
> > > >>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> > > >>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
> > > >>>>> as result 'perf top' shows no events.
> > > >>>>
> > > >>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
> > > >>>> It could well just be that the interrupt numbers are wrong...
> > > >>>
> > > >>> Looks like it does, at least result looks plausible:
> > > >>
> > > >> I'm using perf stat regularly (cache benchmarks) and it works fine.
> > > >>
> > > >> Unfortunately I wasn't aware that perf stat is a poor test for
> > > >> the interrupts part of the node, when I added it. So I'm not too
> > > >> surprised I got it wrong.
> > > >>
> > > >> However, it would be unfortunate if the node got removed completely,
> > > >> because perf stat would not work anymore. Maybe we can only remove
> > > >> the interrupts or just fix them even if the HW doesn't work?
> > > >
> > > > I'm not familiar with PMU driver. Is it possible to get it working
> > > > without interrupts?
> > >
> > > Yup - you get a grumpy message from the driver, it will refuse sampling
> > > events (the ones which weren't working anyway), and if you measure
> > > anything for long enough that a counter overflows you'll get wonky
> > > results. But for counting hardware events over relatively short periods
> > > it'll still do the job.
> >
> > I tried to drop interrupts completely from the node but 'perf top' is
> > still broken. Though now in different way: it complains "cycles: PMU
> > Hardware doesn't support sampling/overflow-interrupts. Try 'perf
> > stat'"
>
> I have no idea if that's the culprit, but what is the state of the
> 0x09010000 register?
What register is that and how do I check it?
> (in particular, are the bits 16-19 and 24 set or not?
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
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] drm: add cache support for arm64
From: Rob Clark @ 2019-08-07 17:30 UTC (permalink / raw)
To: Mark Rutland
Cc: Sean Paul, Maxime Ripard, Catalin Marinas, Maarten Lankhorst,
LKML, dri-devel, David Airlie, Rob Clark, linux-arm-kernel,
Daniel Vetter, Greg Kroah-Hartman, Thomas Gleixner, Will Deacon,
Christoph Hellwig, Allison Randal
In-Reply-To: <20190807164958.GA44765@lakrids.cambridge.arm.com>
On Wed, Aug 7, 2019 at 9:50 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Wed, Aug 07, 2019 at 09:15:54AM -0700, Rob Clark wrote:
> > On Wed, Aug 7, 2019 at 5:38 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > >
> > > On Tue, Aug 06, 2019 at 09:31:55AM -0700, Rob Clark wrote:
> > > > On Tue, Aug 6, 2019 at 7:35 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > > > >
> > > > > On Tue, Aug 06, 2019 at 07:11:41AM -0700, Rob Clark wrote:
> > > > > > On Tue, Aug 6, 2019 at 1:48 AM Christoph Hellwig <hch@lst.de> wrote:
> > > > > > >
> > > > > > > This goes in the wrong direction. drm_cflush_* are a bad API we need to
> > > > > > > get rid of, not add use of it. The reason for that is two-fold:
> > > > > > >
> > > > > > > a) it doesn't address how cache maintaince actually works in most
> > > > > > > platforms. When talking about a cache we three fundamental operations:
> > > > > > >
> > > > > > > 1) write back - this writes the content of the cache back to the
> > > > > > > backing memory
> > > > > > > 2) invalidate - this remove the content of the cache
> > > > > > > 3) write back + invalidate - do both of the above
> > > > > >
> > > > > > Agreed that drm_cflush_* isn't a great API. In this particular case
> > > > > > (IIUC), I need wb+inv so that there aren't dirty cache lines that drop
> > > > > > out to memory later, and so that I don't get a cache hit on
> > > > > > uncached/wc mmap'ing.
> > > > >
> > > > > Is there a cacheable alias lying around (e.g. the linear map), or are
> > > > > these addresses only mapped uncached/wc?
> > > > >
> > > > > If there's a cacheable alias, performing an invalidate isn't sufficient,
> > > > > since a CPU can allocate a new (clean) entry at any point in time (e.g.
> > > > > as a result of prefetching or arbitrary speculation).
> > > >
> > > > I *believe* that there are not alias mappings (that I don't control
> > > > myself) for pages coming from
> > > > shmem_file_setup()/shmem_read_mapping_page()..
> > >
> > > AFAICT, that's regular anonymous memory, so there will be a cacheable
> > > alias in the linear/direct map.
> >
> > tbh, I'm not 100% sure whether there is a cacheable alias, or whether
> > any potential linear map is torn down.
>
> I'm fairly confident that the linear/direct map cacheable alias is not
> torn down when pages are allocated. The gneeric page allocation code
> doesn't do so, and I see nothing the shmem code to do so.
>
> For arm64, we can tear down portions of the linear map, but that has to
> be done explicitly, and this is only possible when using rodata_full. If
> not using rodata_full, it is not possible to dynamically tear down the
> cacheable alias.
So, we do end up using GFP_HIGHUSER, which appears to get passed thru
when shmem gets to the point of actually allocating pages.. not sure
if that just ends up being a hint, or if it guarantees that we don't
get something in the linear map.
(Bear with me while I "page" this all back in.. last time I dug thru
the shmem code was probably pre-armv8, or at least before I had any
armv8 hw)
BR,
-R
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2 v2] tracing: Document the stack trace algorithm in the comments
From: Steven Rostedt @ 2019-08-07 17:28 UTC (permalink / raw)
To: linux-kernel
Cc: Jiping Ma, catalin.marinas, will.deacon, mingo, Joel Fernandes,
linux-arm-kernel
In-Reply-To: <20190807172826.352574408@goodmis.org>
From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
As the max stack tracer algorithm is not that easy to understand from the
code, add comments that explain the algorithm and mentions how
ARCH_RET_ADDR_AFTER_LOCAL_VARS affects it.
Link: http://lkml.kernel.org/r/20190806123455.487ac02b@gandalf.local.home
Suggested-by: Joel Fernandes <joel@joelfernandes.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
kernel/trace/trace_stack.c | 98 ++++++++++++++++++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index 40e4a88eea8f..f94a2fc567de 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -53,6 +53,104 @@ static void print_max_stack(void)
}
}
+/*
+ * The stack tracer looks for a maximum stack at each call from a function. It
+ * registers a callback from ftrace, and in that callback it examines the stack
+ * size. It determines the stack size from the variable passed in, which is the
+ * address of a local variable in the stack_trace_call() callback function.
+ * The stack size is calculated by the address of the local variable to the top
+ * of the current stack. If that size is smaller than the currently saved max
+ * stack size, nothing more is done.
+ *
+ * If the size of the stack is greater than the maximum recorded size, then the
+ * following algorithm takes place.
+ *
+ * For architectures (like x86) that store the function's return address before
+ * saving the function's local variables, the stack will look something like
+ * this:
+ *
+ * [ top of stack ]
+ * 0: sys call entry frame
+ * 10: return addr to entry code
+ * 11: start of sys_foo frame
+ * 20: return addr to sys_foo
+ * 21: start of kernel_func_bar frame
+ * 30: return addr to kernel_func_bar
+ * 31: [ do trace stack here ]
+ *
+ * The save_stack_trace() is called returning all the functions it finds in the
+ * current stack. Which would be (from the bottom of the stack to the top):
+ *
+ * return addr to kernel_func_bar
+ * return addr to sys_foo
+ * return addr to entry code
+ *
+ * Now to figure out how much each of these functions' local variable size is,
+ * a search of the stack is made to find these values. When a match is made, it
+ * is added to the stack_dump_trace[] array. The offset into the stack is saved
+ * in the stack_trace_index[] array. The above example would show:
+ *
+ * stack_dump_trace[] | stack_trace_index[]
+ * ------------------ + -------------------
+ * return addr to kernel_func_bar | 30
+ * return addr to sys_foo | 20
+ * return addr to entry | 10
+ *
+ * The print_max_stack() function above, uses these values to print the size of
+ * each function's portion of the stack.
+ *
+ * for (i = 0; i < nr_entries; i++) {
+ * size = i == nr_entries - 1 ? stack_trace_index[i] :
+ * stack_trace_index[i] - stack_trace_index[i+1]
+ * print "%d %d %d %s\n", i, stack_trace_index[i], size, stack_dump_trace[i]);
+ * }
+ *
+ * The above shows
+ *
+ * depth size location
+ * ----- ---- --------
+ * 0 30 10 kernel_func_bar
+ * 1 20 10 sys_foo
+ * 2 10 10 entry code
+ *
+ * Now for architectures that might save the return address after the functions
+ * local variables (saving the link register before calling nested functions),
+ * this will cause the stack to look a little different:
+ *
+ * [ top of stack ]
+ * 0: sys call entry frame
+ * 10: start of sys_foo_frame
+ * 19: return addr to entry code << lr saved before calling kernel_func_bar
+ * 20: start of kernel_func_bar frame
+ * 29: return addr to sys_foo_frame << lr saved before calling next function
+ * 30: [ do trace stack here ]
+ *
+ * Although the functions returned by save_stack_trace() may be the same, the
+ * placement in the stack will be different. Using the same algorithm as above
+ * would yield:
+ *
+ * stack_dump_trace[] | stack_trace_index[]
+ * ------------------ + -------------------
+ * return addr to kernel_func_bar | 30
+ * return addr to sys_foo | 29
+ * return addr to entry | 19
+ *
+ * Where the mapping is off by one:
+ *
+ * kernel_func_bar stack frame size is 29 - 19 not 30 - 29!
+ *
+ * To fix this, if the architecture sets ARCH_RET_ADDR_AFTER_LOCAL_VARS the
+ * values in stack_trace_index[] are shifted by one to and the number of
+ * stack trace entries is decremented by one.
+ *
+ * stack_dump_trace[] | stack_trace_index[]
+ * ------------------ + -------------------
+ * return addr to kernel_func_bar | 29
+ * return addr to sys_foo | 19
+ *
+ * Although the entry function is not displayed, the first function (sys_foo)
+ * will still include the stack size of it.
+ */
static void check_stack(unsigned long ip, unsigned long *stack)
{
unsigned long this_size, flags; unsigned long *p, *top, *start;
--
2.20.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
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