* Re: Linux next-20190807: arm64: build failed - phy-rockchip-inno-hdmi.c:1046:26: error: anonymous bit-field has negative width (-1)
From: Stephen Rothwell @ 2019-08-08 1:01 UTC (permalink / raw)
To: Naresh Kamboju
Cc: heiko, open list, lkft-triage, kishon, linux-rockchip,
Linux-Next Mailing List, linux-arm-kernel
In-Reply-To: <CA+G9fYvehn=5Rn0RHjFvCc1pCDFTUtxNeR11CQjD6rjM53D4ig@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1770 bytes --]
Hi Naresh,
On Wed, 7 Aug 2019 16:48:15 +0530 Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> Linux next 20190807 arm64 default config build failed due to below error.
>
> /drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:1046:26: error:
> anonymous bit-field has negative width (-1)
> inno_write(inno, 0xc6, RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(v));
> ^
> ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:201:50: note:
> expanded from macro 'RK3328_TERM_RESISTOR_CALIB_SPEED_7_0'
> #define RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(x) UPDATE(x, 7, 9)
> ^
> ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:24:42: note: expanded
> from macro 'UPDATE'
> #define UPDATE(x, h, l) (((x) << (l)) & GENMASK((h), (l)))
> ^
> ../include/linux/bits.h:39:3: note: expanded from macro 'GENMASK'
> (GENMASK_INPUT_CHECK(high, low) + __GENMASK(high, low))
> ^
> ../include/linux/bits.h:24:18: note: expanded from macro 'GENMASK_INPUT_CHECK'
> ((unsigned long)BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> ^
> ../include/linux/build_bug.h:16:47: note: expanded from macro
> 'BUILD_BUG_ON_ZERO'
> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
>
> Config link,
> https://storage.kernelci.org/next/master/next-20190807/arm64/defconfig/clang-8/kernel.config
>
> Build link,
> https://storage.kernelci.org/next/master/next-20190807/arm64/defconfig/clang-8/build.log
I think the patch that caused this has been removed form linux-next for
today (it had other problems as well).
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- 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
* Re: [PATCH] dt-bindings: clock: imx8mn: Fix tab indentation for yaml file
From: Stephen Boyd @ 2019-08-07 23:59 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Sascha Hauer, Anson Huang, Shawn Guo,
Michael Turquette, linux-kernel@vger.kernel.org, NXP Linux Team,
Sascha Hauer, Fabio Estevam, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqKZHG-y_cKitU0=EksgyVU-YLOi1gAcFXx4ve21CMki1g@mail.gmail.com>
Quoting Rob Herring (2019-07-25 14:37:24)
> On Thu, Jul 25, 2019 at 3:06 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Anson.Huang@nxp.com (2019-07-24 19:05:51)
> > > From: Anson Huang <Anson.Huang@nxp.com>
> > >
> > > YAML file can NOT contain tab as indentation, fix it.
> > >
> >
> > Would be nice if checkpatch could check for this.
>
> Would be nice if folks just ran 'make dt_binding_check'. :) It
> wouldn't be hard to add a tab check to checkpatch, but that's just one
> potential problem.
>
Cool, thanks for the pointer. Seems I forgot :)
Here's a patch to improve the documentation and make help to answer
questions I had about how to work this into my workflow.
diff --git a/Documentation/devicetree/writing-schema.md b/Documentation/devicetree/writing-schema.md
index dc032db36262..17ad67887fde 100644
--- a/Documentation/devicetree/writing-schema.md
+++ b/Documentation/devicetree/writing-schema.md
@@ -120,6 +120,7 @@ This will first run the `dt_binding_check` which generates the processed schema.
It is also possible to run checks with a single schema file by setting the
'DT_SCHEMA_FILES' variable to a specific schema file.
+`make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml`
`make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml`
diff --git a/Makefile b/Makefile
index 9be5834073f8..96bb28aa1c46 100644
--- a/Makefile
+++ b/Makefile
@@ -1503,8 +1503,10 @@ help:
@echo ''
@$(if $(dtstree), \
echo 'Devicetree:'; \
- echo '* dtbs - Build device tree blobs for enabled boards'; \
- echo ' dtbs_install - Install dtbs to $(INSTALL_DTBS_PATH)'; \
+ echo '* dtbs - Build device tree blobs for enabled boards'; \
+ echo ' dtbs_install - Install dtbs to $(INSTALL_DTBS_PATH)'; \
+ echo ' dt_binding_check - Validate device tree binding documents'; \
+ echo ' dtbs_check - Validate device tree source files'; \
echo '')
@echo 'Userspace tools targets:'
_______________________________________________
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: [RFCv3 1/3] dt-bindings: interconnect: Add bindings for imx
From: Leonard Crestez @ 2019-08-07 22:35 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring
Cc: Mark Rutland, Artur Świgoń, Jacky Bai, Saravana Kannan,
Anson Huang, Stephen Boyd, Viresh Kumar, Michael Turquette,
linux-pm@vger.kernel.org, Krzysztof Kozlowski, Chanwoo Choi,
Kyungmin Park, MyungJoo Ham, Alexandre Bailon,
kernel@pengutronix.de, Fabio Estevam,
linux-arm-kernel@lists.infradead.org, Shawn Guo, Aisheng Dong,
devicetree@vger.kernel.org, dl-linux-imx
In-Reply-To: <123536fc-c3ce-5bfe-fbd6-20cde0c13cc0@linaro.org>
On 8/7/2019 6:16 PM, Georgi Djakov wrote:
> Please put some commit text.
Will fix
>> +properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - fsl,imx8mm-interconnect
>
> Maybe fsl,imx8mm-busfreq? I thought it's called busfreq in downstream, but it's
> up to you.
In the vendor tree busfreq is effectively its own subsystem with its own
API calls used by imx drivers. As part of replacing this with standard
devfreq + interconnect in upstream the old name should go away.
--
Regards,
Leonard
_______________________________________________
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: versatile: Add of_node_put() in cm_osc_setup()
From: Stephen Boyd @ 2019-08-07 22:25 UTC (permalink / raw)
To: Nishka Dasgupta, linus.walleij, linux-arm-kernel, linux-clk,
mturquette
Cc: Nishka Dasgupta
In-Reply-To: <20190804163445.6862-1-nishkadg.linux@gmail.com>
Quoting Nishka Dasgupta (2019-08-04 09:34:44)
> In function cm_osc_setup, variable parent takes the value returned by
> of_get_parent, which gets a node but does not put it. If parent is not
> put before it goes out of scope, it may cause a memory leak.
> Hence put parent before the function terminates.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
> ---
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
* [PATCH v3 2/2] iommu/arm-smmu: Add support for Adreno GPU pagetable formats
From: Jordan Crouse @ 2019-08-07 22:21 UTC (permalink / raw)
To: freedreno
Cc: Will Deacon, jean-philippe.brucker, linux-arm-msm, Joerg Roedel,
linux-kernel, iommu, robin.murphy, linux-arm-kernel
In-Reply-To: <1565216500-28506-1-git-send-email-jcrouse@codeaurora.org>
Add support for an Adreno GPU variant of the arm-smmu device to enable
a special pagetable format that enables TTBR1 and leaves TTBR0 free
to be switched by the GPU hardware.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/iommu/arm-smmu.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index aa06498..129ac83 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -124,6 +124,7 @@ enum arm_smmu_implementation {
ARM_MMU500,
CAVIUM_SMMUV2,
QCOM_SMMUV2,
+ ADRENO_SMMUV2,
};
struct arm_smmu_s2cr {
@@ -832,7 +833,10 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
ias = smmu->va_size;
oas = smmu->ipa_size;
if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH64) {
- fmt = ARM_64_LPAE_S1;
+ if (smmu->model == ADRENO_SMMUV2)
+ fmt = ARM_ADRENO_GPU_LPAE;
+ else
+ fmt = ARM_64_LPAE_S1;
} else if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH32_L) {
fmt = ARM_32_LPAE_S1;
ias = min(ias, 32UL);
@@ -2030,6 +2034,7 @@ ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K, GENERIC_SMMU);
ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
ARM_SMMU_MATCH_DATA(qcom_smmuv2, ARM_SMMU_V2, QCOM_SMMUV2);
+ARM_SMMU_MATCH_DATA(adreno_smmuv2, ARM_SMMU_V2, ADRENO_SMMUV2);
static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v1", .data = &smmu_generic_v1 },
@@ -2039,6 +2044,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,mmu-500", .data = &arm_mmu500 },
{ .compatible = "cavium,smmu-v2", .data = &cavium_smmuv2 },
{ .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
+ { .compatible = "qcom,adreno-smmu-v2", .data = &adreno_smmuv2 },
{ },
};
--
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 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
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