* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Javier Martinez Canillas @ 2017-12-11 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=mUHgTxvYpOYstE7rQn8fKS3QGiTT=FzBUc8DREvVuTeQ@mail.gmail.com>
On Mon, Dec 11, 2017 at 11:28 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> [adding Marek and Shuah to cc list]
[snip]
>>>
>>> Please see below, I've had several bisection results pointing at
>>> that commit over the week-end on mainline but also on linux-next
>>> and net-next. While the peach-pi is a bit flaky at the moment
>>> and is likely to have more than one issue, it does seem like this
>>> commit is causing some well reproducible kernel hang.
>>>
>>> Here's a re-run with v4.15-rc3 showing the issue:
>>>
>>> https://lava.collabora.co.uk/scheduler/job/1018478
>>>
>>> and here's another one with the change mentioned below reverted:
>>>
>>> https://lava.collabora.co.uk/scheduler/job/1018479
>>>
>>> They both show a warning about "unbalanced disables for lcd_vdd",
>>> I don't know if this is related as I haven't investigated any
>>> further. It does appear to reliably hang with v4.15-rc3 and
>>> boot most of the time with the commit reverted though.
>>>
>>> The automated kernelci.org bisection is still an experimental
>>> tool and it may well be a false positive, so please take this
>>> result with a pinch of salt...
>>
>> The patch just very minimal moves the connector cleanup around (so
>> timing change), but except when you unload a driver (or maybe that
>> funny EPROBE_DEFER stuff) it shouldn't matter. So if you don't have
>> more info than "seems to hang a bit more" I have no idea what's wrong.
>> The patch itself should work, at least it survived quite some serious
>> testing we do on everything.
>> -Daniel
>>
>
> Marek was pointing to a different culprit [0] in this [1] thread. I
> see that both commits made it to v4.15-rc3, which is the first version
> where boot fails. So maybe is a combination of both? Or rather
> reverting one patch masks the error in the other.
>
> I've access to the machine but unfortunately not a lot of time to dig
> on this, I could try to do it in the weekend though.
>
> [0]: https://patchwork.kernel.org/patch/10067711/
> [1]: https://www.spinics.net/lists/arm-kernel/msg622152.html
>
So I gave a quick look to this, and at the very least there's a bug in
the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
exynos: Add status property to Exynos 542x Mixer nodes").
I've posted a fix for that:
https://patchwork.kernel.org/patch/10105921/
I believe this could be also be the cause for the boot failure, since
I see in the boot log that things start to go wrong after exynos-drm
fails to bind the HDMI component:
[ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
0xc1398690): -1
Anyway, I don't have access to the machine now, but it would be nice
if someone test. Or I would do in a few days.
Best regards,
Javier
^ permalink raw reply
* [RFT PATCH] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Javier Martinez Canillas @ 2017-12-11 22:48 UTC (permalink / raw)
To: linux-arm-kernel
Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
for each Exynos 542x DTS. But unfortunately it missed to enable it for the
Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---
I believe this may cause the boot issues reported on Exynos5800 Peach Pi
from v4.15-rc3, the mentioned commit made to v4.15-rc1 but it seems that
didn't cause any harm until commit ("510353a63796 drm/bridge: analogix
dp: Fix runtime PM state in get_modes() callback") fixed the runtime PM
management in the DP driver.
I can't test right now, but I'm posting anyways as a RFT in case others
that have access to a Peach Pi can test it.
Best regards,
Javier
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index b2b95ff205e8..0029ec27819c 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -664,6 +664,10 @@
status = "okay";
};
+&mixer {
+ status = "okay";
+};
+
/* eMMC flash */
&mmc_0 {
status = "okay";
--
2.14.3
^ permalink raw reply related
* [PATCH v4 5/5] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
From: Lukasz Majewski @ 2017-12-11 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <SN1PR0101MB156535B0FBBAF51FE274F0A7D0370@SN1PR0101MB1565.prod.exchangelabs.com>
Hi Hartley,
> On Monday, December 11, 2017 2:40 PM, Lukasz Majewski wrote:
> > Hi Hartley,
> >
> >> On Thursday, November 30, 2017 4:52 PM, Lukasz Majewski wrote:
> >>>
> >>> The BK3 board is a derivative of the ts72xx reference design.
> >>
> >> Lukasz,
> >>
> >> I was just reviewing the other TS-72xx boards and noticed this:
> >>
> >> <snip>
> >>
> >>> +/* BK3 specific defines */
> >>> +#define BK3_CPLDVER_PHYS_BASE 0x23400000
> >>> +#define BK3_CPLDVER_VIRT_BASE 0xfebfd000
> >>> +#define BK3_CPLDVER_SIZE 0x00001000
> >>> +
> >>
> >> <snip>
> >>
> >>> +static struct map_desc bk3_io_desc[] __initdata = {
> >>> + {
> >>> + .virtual = BK3_CPLDVER_VIRT_BASE,
> >>> + .pfn =
> >>> __phys_to_pfn(BK3_CPLDVER_PHYS_BASE),
> >>> + .length = BK3_CPLDVER_SIZE,
> >>> + .type = MT_DEVICE,
> >>> + }
> >>> +};
> >>> +
> >>
> >> This register appears to be common to all the TS-72xx boards.
> >
> > The CPLD was used on the reference ts-72xx boards, but support for
> > it seems to not be present in the mainline kernel.
>
> The CPLD is not directly called out but some parts of it are
> supported in the mainline kernel.
>
> The RTC index and data registers are chip selected by the CPLD and
> Watchdog is in the CPLD. Also, the model number, options, and
> options2 registers are in the CPLD.
>
> There are a couple other registers in the CPLD that are not currently
> present in mainline. Some aren't because I haven't figured a good way
> to utilize them (the COM2 RS485 registers and the PC/104 memory/IO
> spaces) or they simply have not been necessary yet (the two status
> registers). There are a couple listed in the manuals that are
> specific to the TS-7260 that also have not been added.
>
> Basically, anything in the EP93xx CS1 or CS2 memory region is in or
> controlled by the CPLD.
>
> > Do you have a ts72xx board with CPLD embedded? Is any of your
> > design using it?
>
> I have a stock TS-7300 board.
>
> > My another concern - is it safe to perform IO mapping on memory
> > regions which are not used / specified?
>
> The mapping is safe. If there is nothing at the address you just read
> back the static state (noise) of the bus and writing doesn't do
> anything.
Ok.
>
> > When I do a single ts72xx mapping - for all boards - then we may
> > end up with some mappings which are not needed.
>
> True, but it's harmless and it keeps the platform init code cleaner.
I will add all the mappings.
>
> > With the code as it is - I only map regions which are already used
> > on relevant boards.
>
> Yes, but this register in particular exists in the CPLD on all the
> TS-72xx boards.
>
> >> I don't think Arnd has pulled the series yet. Would you mind
> >> renaming the defines and rebasing this patch?
> >
> > If needed I can resend the patch series, or prepare a single fix
> > patch. No problem.
>
> Fixing it after Arnd merges your series is fine. I just wanted to
> make sure it was pointed out.
I've checked a few minutes ago and it seems like arm-soc hasn't been
pulled to for-next.
I may resend the whole series.
>
> BTW, is there a reason the BK3 board needs this register mapped? It
> was mapped in the Technologic Systems 2.4, 2.6, and 3.x kernels but I
> never found anything that used it.
It is used to check the version. BK3 has some CPLD modifications and
it is important to know which version we do have as the board is
already deployed for some time in the field.
> Of course the stock boards
> probably always had the same revision in the CPLD, the BK3 board
> might have multiple revisions...
Yes, correct.
>
> Hartley
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171211/4003dd39/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 2/2] arm64: Add software workaround for Falkor erratum 1041
From: Shanker Donthineni @ 2017-12-11 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513032152-13211-1-git-send-email-shankerd@codeaurora.org>
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter 4K and next 4K.
When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.
1) A System Error Interrupt (SEI) being raised by the Falkor core due
to the errant memory access attempting to access a region of memory
that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
memory. This behavior may only occur if the instruction cache is
disabled prior to or coincident with translation being changed from
enabled to disabled.
The conditions leading to this erratum will not occur when either of the
following occur:
1) A higher exception level disables translation of a lower exception level
(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
2) An exception level disabling its stage-1 translation if its stage-2
translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
---
Changes since v3:
Rebased to kernel v4.15-rc3 and removed the alternatives.
Changes since v3:
Rebased to kernel v4.15-rc1.
Changes since v2:
Repost the corrected patches.
Changes since v1:
Apply the workaround where it's required.
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 12 +++++++++++-
arch/arm64/include/asm/assembler.h | 10 ++++++++++
arch/arm64/kernel/cpu-reset.S | 1 +
arch/arm64/kernel/efi-entry.S | 2 ++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/relocate_kernel.S | 1 +
arch/arm64/kvm/hyp-init.S | 1 +
8 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 304bf22..fc1c884 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -75,3 +75,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
+| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a93339f..c9a7e9e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -557,7 +557,6 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
-
config SOCIONEXT_SYNQUACER_PREITS
bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
default y
@@ -576,6 +575,17 @@ config HISILICON_ERRATUM_161600802
a 128kB offset to be applied to the target address in this commands.
If unsure, say Y.
+
+config QCOM_FALKOR_ERRATUM_E1041
+ bool "Falkor E1041: Speculative instruction fetches might cause errant memory access"
+ default y
+ help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index aef72d8..8b16828 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -512,4 +512,14 @@
#endif
.endm
+/**
+ * Errata workaround prior to disable MMU. Insert an ISB immediately prior
+ * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
+ */
+ .macro pre_disable_mmu_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+ isb
+#endif
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 65f42d2..2a752cb 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -37,6 +37,7 @@ ENTRY(__cpu_soft_restart)
mrs x12, sctlr_el1
ldr x13, =SCTLR_ELx_FLAGS
bic x12, x12, x13
+ pre_disable_mmu_workaround
msr sctlr_el1, x12
isb
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index 4e6ad35..6b9736c 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -96,6 +96,7 @@ ENTRY(entry)
mrs x0, sctlr_el2
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
+ pre_disable_mmu_workaround
msr sctlr_el2, x0
isb
b 2f
@@ -103,6 +104,7 @@ ENTRY(entry)
mrs x0, sctlr_el1
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
+ pre_disable_mmu_workaround
msr sctlr_el1, x0
isb
2:
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 67e86a0..e3cb9fb 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -750,6 +750,7 @@ __primary_switch:
* to take into account by discarding the current kernel mapping and
* creating a new one.
*/
+ pre_disable_mmu_workaround
msr sctlr_el1, x20 // disable the MMU
isb
bl __create_page_tables // recreate kernel mapping
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index ce704a4..f407e42 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -45,6 +45,7 @@ ENTRY(arm64_relocate_new_kernel)
mrs x0, sctlr_el2
ldr x1, =SCTLR_ELx_FLAGS
bic x0, x0, x1
+ pre_disable_mmu_workaround
msr sctlr_el2, x0
isb
1:
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 3f96155..870828c 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -151,6 +151,7 @@ reset:
mrs x5, sctlr_el2
ldr x6, =SCTLR_ELx_FLAGS
bic x5, x5, x6 // Clear SCTL_M and etc
+ pre_disable_mmu_workaround
msr sctlr_el2, x5
isb
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v5 1/2] arm64: Define cputype macros for Falkor CPU
From: Shanker Donthineni @ 2017-12-11 22:42 UTC (permalink / raw)
To: linux-arm-kernel
Add cputype definition macros for Qualcomm Datacenter Technologies
Falkor CPU in cputype.h. It's unfortunate that the first revision
of the Falkor CPU used the wrong part number 0x800, got fixed in v2
chip with part number 0xC00, and would be used the same value for
future revisions.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d..cbf08d7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -91,6 +91,7 @@
#define BRCM_CPU_PART_VULCAN 0x516
#define QCOM_CPU_PART_FALKOR_V1 0x800
+#define QCOM_CPU_PART_FALKOR 0xC00
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
@@ -99,6 +100,7 @@
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
#define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
+#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR)
#ifndef __ASSEMBLY__
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* next/master boot: 270 boots: 35 failed, 213 passed with 20 offline, 2 untried/unknown (next-20171207)
From: Shuah Khan @ 2017-12-11 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b46b554a-eab0-6167-3fb2-484cd1f11ffd@samsung.com>
Hi Marek,
On 12/11/2017 03:43 AM, Marek Szyprowski wrote:
> Hi Shuah,
>
> Do you have a bit of spare time for Exynos kernel development? Could you investigate why Peach-Pi(t) Chromebooks fails to boot with recent kernels? If I remember correctly, you had access to those boards.
Unfortunately I don't have Peach-Pi(t) Chromebook.
thanks,
-- Shuah
^ permalink raw reply
* [v7, 3/3] ARM: dts: imx6qdl.dtsi/imx6ul.dtsi: add "fsl, imx6q-snvs-lpgpr" node
From: Maciej S. Szmigiero @ 2017-12-11 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170620070932.10353-4-o.rempel@pengutronix.de>
On 20.06.2017 09:09, Oleksij Rempel wrote:
> This node is for Low Power General Purpose Register which can
> be used as Non-Volatile Storage.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> arch/arm/boot/dts/imx6qdl.dtsi | 4 ++++
> arch/arm/boot/dts/imx6ul.dtsi | 4 ++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index e426faa9c243..94e992558238 100644
(..)
FYI: It looks to me that while the driver itself from this series was
picked up and eventually reached Linus' tree this DT change was
forgotten, since I can't find in any tree (or am I not looking at the
right place?).
Maciej
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Javier Martinez Canillas @ 2017-12-11 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKMK7uFcGftSeQjkKu9SZmkQd8-irbUTMcOnUwi7HZtb5TePag@mail.gmail.com>
[adding Marek and Shuah to cc list]
On Mon, Dec 11, 2017 at 6:05 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Mon, Dec 11, 2017 at 11:30 AM, Guillaume Tucker
> <guillaume.tucker@collabora.com> wrote:
>> Hi Daniel,
>>
>> Please see below, I've had several bisection results pointing at
>> that commit over the week-end on mainline but also on linux-next
>> and net-next. While the peach-pi is a bit flaky at the moment
>> and is likely to have more than one issue, it does seem like this
>> commit is causing some well reproducible kernel hang.
>>
>> Here's a re-run with v4.15-rc3 showing the issue:
>>
>> https://lava.collabora.co.uk/scheduler/job/1018478
>>
>> and here's another one with the change mentioned below reverted:
>>
>> https://lava.collabora.co.uk/scheduler/job/1018479
>>
>> They both show a warning about "unbalanced disables for lcd_vdd",
>> I don't know if this is related as I haven't investigated any
>> further. It does appear to reliably hang with v4.15-rc3 and
>> boot most of the time with the commit reverted though.
>>
>> The automated kernelci.org bisection is still an experimental
>> tool and it may well be a false positive, so please take this
>> result with a pinch of salt...
>
> The patch just very minimal moves the connector cleanup around (so
> timing change), but except when you unload a driver (or maybe that
> funny EPROBE_DEFER stuff) it shouldn't matter. So if you don't have
> more info than "seems to hang a bit more" I have no idea what's wrong.
> The patch itself should work, at least it survived quite some serious
> testing we do on everything.
> -Daniel
>
Marek was pointing to a different culprit [0] in this [1] thread. I
see that both commits made it to v4.15-rc3, which is the first version
where boot fails. So maybe is a combination of both? Or rather
reverting one patch masks the error in the other.
I've access to the machine but unfortunately not a lot of time to dig
on this, I could try to do it in the weekend though.
[0]: https://patchwork.kernel.org/patch/10067711/
[1]: https://www.spinics.net/lists/arm-kernel/msg622152.html
Best regards,
Javier
>> Hope this helps!
>>
>> Best wishes,
>> Guillaume
>>
>>
>> -------- Forwarded Message --------
>> Subject: mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
>> Date: Mon, 11 Dec 2017 08:25:55 +0000 (UTC)
>> From: kernelci.org bot <bot@kernelci.org>
>> To: guillaume.tucker at collabora.com
>>
>> Bisection result for mainline/master (v4.15-rc3) on peach-pi
>>
>> Good known revision:
>>
>> c6b3e96 Merge branch 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
>>
>> Bad known revision:
>>
>> 50c4c4e Linux 4.15-rc3
>>
>> Extra parameters:
>>
>> Tree: mainline
>> Branch: master
>> Target: peach-pi
>> Lab: lab-collabora
>> Defconfig: exynos_defconfig
>> Plan: boot
>>
>>
>> Breaking commit found:
>>
>> -------------------------------------------------------------------------------
>> commit a703c55004e1c5076d57e43771b3e11117796ea0
>> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Date: Mon Dec 4 21:48:18 2017 +0100
>>
>> drm: safely free connectors from connector_iter
>> In
>> commit 613051dac40da1751ab269572766d3348d45a197
>> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Date: Wed Dec 14 00:08:06 2016 +0100
>> drm: locking&new iterators for connector_list
>> we've went to extreme lengths to make sure connector iterations
>> works
>> in any context, without introducing any additional locking context.
>> This worked, except for a small fumble in the implementation:
>> When we actually race with a concurrent connector unplug event, and
>> our temporary connector reference turns out to be the final one, then
>> everything breaks: We call the connector release function from
>> whatever context we happen to be in, which can be an irq/atomic
>> context. And connector freeing grabs all kinds of locks and stuff.
>> Fix this by creating a specially safe put function for
>> connetor_iter,
>> which (in this rare case) punts the cleanup to a worker.
>> Reported-by: Ben Widawsky <ben@bwidawsk.net>
>> Cc: Ben Widawsky <ben@bwidawsk.net>
>> Fixes: 613051dac40d ("drm: locking&new iterators for connector_list")
>> Cc: Dave Airlie <airlied@gmail.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Sean Paul <seanpaul@chromium.org>
>> Cc: <stable@vger.kernel.org> # v4.11+
>> Reviewed-by: Dave Airlie <airlied@gmail.com>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> Link:
>> https://patchwork.freedesktop.org/patch/msgid/20171204204818.24745-1-daniel.vetter at ffwll.ch
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index 25f4b2e..4820141 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -152,6 +152,16 @@ static void drm_connector_free(struct kref *kref)
>> connector->funcs->destroy(connector);
>> }
>> +static void drm_connector_free_work_fn(struct work_struct *work)
>> +{
>> + struct drm_connector *connector =
>> + container_of(work, struct drm_connector, free_work);
>> + struct drm_device *dev = connector->dev;
>> +
>> + drm_mode_object_unregister(dev, &connector->base);
>> + connector->funcs->destroy(connector);
>> +}
>> +
>> /**
>> * drm_connector_init - Init a preallocated connector
>> * @dev: DRM device
>> @@ -181,6 +191,8 @@ int drm_connector_init(struct drm_device *dev,
>> if (ret)
>> return ret;
>> + INIT_WORK(&connector->free_work, drm_connector_free_work_fn);
>> +
>> connector->base.properties = &connector->properties;
>> connector->dev = dev;
>> connector->funcs = funcs;
>> @@ -529,6 +541,18 @@ void drm_connector_list_iter_begin(struct drm_device
>> *dev,
>> }
>> EXPORT_SYMBOL(drm_connector_list_iter_begin);
>> +/*
>> + * Extra-safe connector put function that works in any context. Should only
>> be
>> + * used from the connector_iter functions, where we never really expect to
>> + * actually release the connector when dropping our final reference.
>> + */
>> +static void
>> +drm_connector_put_safe(struct drm_connector *conn)
>> +{
>> + if (refcount_dec_and_test(&conn->base.refcount.refcount))
>> + schedule_work(&conn->free_work);
>> +}
>> +
>> /**
>> * drm_connector_list_iter_next - return next connector
>> * @iter: connectr_list iterator
>> @@ -561,7 +585,7 @@ drm_connector_list_iter_next(struct
>> drm_connector_list_iter *iter)
>> spin_unlock_irqrestore(&config->connector_list_lock, flags);
>> if (old_conn)
>> - drm_connector_put(old_conn);
>> + drm_connector_put_safe(old_conn);
>> return iter->conn;
>> }
>> @@ -580,7 +604,7 @@ void drm_connector_list_iter_end(struct
>> drm_connector_list_iter *iter)
>> {
>> iter->dev = NULL;
>> if (iter->conn)
>> - drm_connector_put(iter->conn);
>> + drm_connector_put_safe(iter->conn);
>> lock_release(&connector_list_iter_dep_map, 0, _RET_IP_);
>> }
>> EXPORT_SYMBOL(drm_connector_list_iter_end);
>> diff --git a/drivers/gpu/drm/drm_mode_config.c
>> b/drivers/gpu/drm/drm_mode_config.c
>> index cda8bfa..cc78b3d 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -431,6 +431,8 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>> drm_connector_put(connector);
>> }
>> drm_connector_list_iter_end(&conn_iter);
>> + /* connector_iter drops references in a work item. */
>> + flush_scheduled_work();
>> if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) {
>> drm_connector_list_iter_begin(dev, &conn_iter);
>> drm_for_each_connector_iter(connector, &conn_iter)
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index df9807a..a4649c5 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -916,6 +916,14 @@ struct drm_connector {
>> uint8_t num_h_tile, num_v_tile;
>> uint8_t tile_h_loc, tile_v_loc;
>> uint16_t tile_h_size, tile_v_size;
>> +
>> + /**
>> + * @free_work:
>> + *
>> + * Work used only by &drm_connector_iter to be able to clean up a
>> + * connector from any context.
>> + */
>> + struct work_struct free_work;
>> };
>> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
>> -------------------------------------------------------------------------------
>>
>>
>> Git bisection log:
>>
>> -------------------------------------------------------------------------------
>> git bisect start
>> # good: [c6b3e9693f8a32ba3b07e2f2723886ea2aff4e94] Merge branch 'for-linus'
>> of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
>> git bisect good c6b3e9693f8a32ba3b07e2f2723886ea2aff4e94
>> # bad: [50c4c4e268a2d7a3e58ebb698ac74da0de40ae36] Linux 4.15-rc3
>> git bisect bad 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36
>> # bad: [e9ef1fe312b533592e39cddc1327463c30b0ed8d] Merge
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>> git bisect bad e9ef1fe312b533592e39cddc1327463c30b0ed8d
>> # bad: [77071bc6c472bb0b36818f3e9595114cdf98c86d] Merge tag 'media/v4.15-2'
>> of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
>> git bisect bad 77071bc6c472bb0b36818f3e9595114cdf98c86d
>> # bad: [4066aa72f9f2886105c6f747d7f9bd4f14f53c12] Merge tag
>> 'drm-fixes-for-v4.15-rc3' of git://people.freedesktop.org/~airlied/linux
>> git bisect bad 4066aa72f9f2886105c6f747d7f9bd4f14f53c12
>> # bad: [96980844bb4b74d2e7ce93d907670658e39a3992] Merge tag
>> 'drm-intel-fixes-2017-12-07' of git://anongit.freedesktop.org/drm/drm-intel
>> into drm-fixes
>> git bisect bad 96980844bb4b74d2e7ce93d907670658e39a3992
>> # bad: [120a264f9c2782682027d931d83dcbd22e01da80] drm/exynos: gem: Drop
>> NONCONTIG flag for buffers allocated without IOMMU
>> git bisect bad 120a264f9c2782682027d931d83dcbd22e01da80
>> # good: [2bf257d662509553ae226239e7dc1c3d00636ca6] drm/ttm: roundup the
>> shrink request to prevent skip huge pool
>> git bisect good 2bf257d662509553ae226239e7dc1c3d00636ca6
>> # good: [db8f884ca7fe6af64d443d1510464efe23826131] Merge branch
>> 'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
>> git bisect good db8f884ca7fe6af64d443d1510464efe23826131
>> # bad: [bd3a3a2e92624942a143e485c83e641b2492d828] Merge tag
>> 'drm-misc-fixes-2017-12-06' of git://anongit.freedesktop.org/drm/drm-misc
>> into drm-fixes
>> git bisect bad bd3a3a2e92624942a143e485c83e641b2492d828
>> # bad: [a703c55004e1c5076d57e43771b3e11117796ea0] drm: safely free
>> connectors from connector_iter
>> git bisect bad a703c55004e1c5076d57e43771b3e11117796ea0
>> # first bad commit: [a703c55004e1c5076d57e43771b3e11117796ea0] drm: safely
>> free connectors from connector_iter
>> -------------------------------------------------------------------------------
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 5/5] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
From: Hartley Sweeten @ 2017-12-11 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211223941.744be82f@jawa>
On Monday, December 11, 2017 2:40 PM, Lukasz Majewski wrote:
> Hi Hartley,
>
>> On Thursday, November 30, 2017 4:52 PM, Lukasz Majewski wrote:
>>>
>>> The BK3 board is a derivative of the ts72xx reference design.
>>
>> Lukasz,
>>
>> I was just reviewing the other TS-72xx boards and noticed this:
>>
>> <snip>
>>
>>> +/* BK3 specific defines */
>>> +#define BK3_CPLDVER_PHYS_BASE 0x23400000
>>> +#define BK3_CPLDVER_VIRT_BASE 0xfebfd000
>>> +#define BK3_CPLDVER_SIZE 0x00001000
>>> +
>>
>> <snip>
>>
>>> +static struct map_desc bk3_io_desc[] __initdata = {
>>> + {
>>> + .virtual = BK3_CPLDVER_VIRT_BASE,
>>> + .pfn =
>>> __phys_to_pfn(BK3_CPLDVER_PHYS_BASE),
>>> + .length = BK3_CPLDVER_SIZE,
>>> + .type = MT_DEVICE,
>>> + }
>>> +};
>>> +
>>
>> This register appears to be common to all the TS-72xx boards.
>
> The CPLD was used on the reference ts-72xx boards, but support for it seems
> to not be present in the mainline kernel.
The CPLD is not directly called out but some parts of it are supported in the mainline
kernel.
The RTC index and data registers are chip selected by the CPLD and Watchdog is in
the CPLD. Also, the model number, options, and options2 registers are in the CPLD.
There are a couple other registers in the CPLD that are not currently present in
mainline. Some aren't because I haven't figured a good way to utilize them (the
COM2 RS485 registers and the PC/104 memory/IO spaces) or they simply have not
been necessary yet (the two status registers). There are a couple listed in the manuals
that are specific to the TS-7260 that also have not been added.
Basically, anything in the EP93xx CS1 or CS2 memory region is in or controlled by the CPLD.
> Do you have a ts72xx board with CPLD embedded? Is any of your design using it?
I have a stock TS-7300 board.
> My another concern - is it safe to perform IO mapping on memory regions which are
> not used / specified?
The mapping is safe. If there is nothing at the address you just read back the static state
(noise) of the bus and writing doesn't do anything.
> When I do a single ts72xx mapping - for all boards - then we may end up with some
> mappings which are not needed.
True, but it's harmless and it keeps the platform init code cleaner.
> With the code as it is - I only map regions which are already used on relevant boards.
Yes, but this register in particular exists in the CPLD on all the TS-72xx boards.
>> I don't think Arnd has pulled the series yet. Would you mind renaming
>> the defines and rebasing this patch?
>
> If needed I can resend the patch series, or prepare a single fix patch.
> No problem.
Fixing it after Arnd merges your series is fine. I just wanted to make sure it was
pointed out.
BTW, is there a reason the BK3 board needs this register mapped? It was mapped
in the Technologic Systems 2.4, 2.6, and 3.x kernels but I never found anything that
used it. Of course the stock boards probably always had the same revision in the CPLD,
the BK3 board might have multiple revisions...
Hartley
^ permalink raw reply
* [RESEND PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
From: Shanker Donthineni @ 2017-12-11 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211104558.pm3lijsdfg2xhj7h@lakrids.cambridge.arm.com>
Thanks Mark, I'll post v5 patch without alternatives.
On 12/11/2017 04:45 AM, Mark Rutland wrote:
> Hi,
>
> On Sun, Dec 10, 2017 at 08:03:43PM -0600, Shanker Donthineni wrote:
>> +/**
>> + * Errata workaround prior to disable MMU. Insert an ISB immediately prior
>> + * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
>> + */
>> + .macro pre_disable_mmu_workaround
>> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
>> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
>> + isb
>> +alternative_else_nop_endif
>> +#endif
>> + .endm
>
> There's really no need for this to be an alternative. It makes the
> kernel larger and more complex due to all the altinstr data and probing
> code.
>
> As Will suggested last time [1], please just use the ifdef, and always
> compile-in the extra ISB if CONFIG_QCOM_FALKOR_ERRATUM_E1041 is
> selected. Get rid of the alternatives and probing code.
>
> All you need here is:
>
> /*
> * Some Falkor parts make errant speculative instruction fetches
> * when SCTLR_ELx.M is cleared. An ISB before the write to
> * SCTLR_ELx prevents this.
> */
> .macro pre_disable_mmu_workaround
> #ifdef
> isb
> #endif
> .endm
>
>> +
>> + .macro pre_disable_mmu_early_workaround
>> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
>> + isb
>> +#endif
>> + .endm
>> +
>
> ... and we don't need a special early variant.
>
> Thanks,
> Mark.
>
> [1] https://lkml.kernel.org/r/20171201112457.GE18083 at arm.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU
From: Kevin Hilman @ 2017-12-11 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4357a69da97f46a324eec4c766f4bc9d9e7733ff.1490545262.git-series.plaes@plaes.org>
On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes <plaes@plaes.org> wrote:
> Convert sun4i-a10.dtsi to new CCU driver.
>
> Signed-off-by: Priit Laes <plaes@plaes.org>
I finally got around to bisecting a mainline boot failure on
sun4i-a10-cubieboard that's been happening for quite a while. Based
on on kernelci.org, it showed up sometime during the v4.15 merge
window[1]. It bisected down to this commit (in mainline as commit
41193869f2bdb585ce09bfdd16d9482aadd560ad).
When it fails, there is no output on the serial console, so I don't
know exactly how it's failing, just that it no longer boots.
Kevin
[1] https://kernelci.org/boot/id/5a2e10cd59b51430a9afa173/
> ---
> arch/arm/boot/dts/sun4i-a10.dtsi | 636 ++++----------------------------
> 1 file changed, 82 insertions(+), 554 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> index ba20b48..0d8320a 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -45,7 +45,8 @@
>
> #include <dt-bindings/thermal/thermal.h>
>
> -#include <dt-bindings/clock/sun4i-a10-pll2.h>
> +#include <dt-bindings/clock/sunxi-a10-a20-ccu.h>
> +#include <dt-bindings/reset/sunxi-a10-a20-ccu.h>
> #include <dt-bindings/dma/sun4i-a10.h>
> #include <dt-bindings/pinctrl/sun4i-a10.h>
>
> @@ -65,9 +66,9 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0-hdmi";
> - clocks = <&ahb_gates 36>, <&ahb_gates 43>,
> - <&ahb_gates 44>, <&de_be0_clk>,
> - <&tcon0_ch1_clk>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI1>,
> + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_DE_BE0>,
> + <&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_DE_BE0>;
> status = "disabled";
> };
>
> @@ -75,10 +76,11 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_fe0-de_be0-lcd0-hdmi";
> - clocks = <&ahb_gates 36>, <&ahb_gates 43>,
> - <&ahb_gates 44>, <&ahb_gates 46>,
> - <&de_be0_clk>, <&de_fe0_clk>, <&tcon0_ch1_clk>,
> - <&dram_gates 25>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI1>,
> + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
> + <&ccu CLK_DE_BE0>, <&ccu CLK_DE_FE0>,
> + <&ccu CLK_TCON0_CH1>,
> + <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
> status = "disabled";
> };
>
> @@ -86,9 +88,10 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_fe0-de_be0-lcd0";
> - clocks = <&ahb_gates 36>, <&ahb_gates 44>, <&ahb_gates 46>,
> - <&de_be0_clk>, <&de_fe0_clk>, <&tcon0_ch0_clk>,
> - <&dram_gates 25>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_DE_BE0>,
> + <&ccu CLK_AHB_DE_FE0>, <&ccu CLK_DE_BE0>,
> + <&ccu CLK_DE_FE0>, <&ccu CLK_TCON0_CH1>,
> + <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
> status = "disabled";
> };
>
> @@ -96,11 +99,11 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0";
> - clocks = <&ahb_gates 34>, <&ahb_gates 36>,
> - <&ahb_gates 44>, <&ahb_gates 46>,
> - <&de_be0_clk>, <&de_fe0_clk>,
> - <&tcon0_ch1_clk>, <&dram_gates 5>,
> - <&dram_gates 25>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_TVE0>, <&ccu CLK_AHB_LCD0>,
> + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
> + <&ccu CLK_DE_BE0>, <&ccu CLK_DE_FE0>,
> + <&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_TVE0>,
> + <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
> status = "disabled";
> };
> };
> @@ -112,7 +115,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a8";
> reg = <0x0>;
> - clocks = <&cpu>;
> + clocks = <&ccu CLK_CPU>;
> clock-latency = <244144>; /* 8 32k periods */
> operating-points = <
> /* kHz uV */
> @@ -168,18 +171,6 @@
> #size-cells = <1>;
> ranges;
>
> - /*
> - * This is a dummy clock, to be used as placeholder on
> - * other mux clocks when a specific parent clock is not
> - * yet implemented. It should be dropped when the driver
> - * is complete.
> - */
> - dummy: dummy {
> - #clock-cells = <0>;
> - compatible = "fixed-clock";
> - clock-frequency = <0>;
> - };
> -
> osc24M: clk at 01c20050 {
> #clock-cells = <0>;
> compatible = "allwinner,sun4i-a10-osc-clk";
> @@ -188,487 +179,12 @@
> clock-output-names = "osc24M";
> };
>
> - osc3M: osc3M_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <8>;
> - clock-mult = <1>;
> - clocks = <&osc24M>;
> - clock-output-names = "osc3M";
> - };
> -
> osc32k: clk at 0 {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> clock-frequency = <32768>;
> clock-output-names = "osc32k";
> };
> -
> - pll1: clk at 01c20000 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll1-clk";
> - reg = <0x01c20000 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll1";
> - };
> -
> - pll2: clk at 01c20008 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll2-clk";
> - reg = <0x01c20008 0x8>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll2-1x", "pll2-2x",
> - "pll2-4x", "pll2-8x";
> - };
> -
> - pll3: clk at 01c20010 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll3-clk";
> - reg = <0x01c20010 0x4>;
> - clocks = <&osc3M>;
> - clock-output-names = "pll3";
> - };
> -
> - pll3x2: pll3x2_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <1>;
> - clock-mult = <2>;
> - clocks = <&pll3>;
> - clock-output-names = "pll3-2x";
> - };
> -
> - pll4: clk at 01c20018 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll1-clk";
> - reg = <0x01c20018 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll4";
> - };
> -
> - pll5: clk at 01c20020 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll5-clk";
> - reg = <0x01c20020 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll5_ddr", "pll5_other";
> - };
> -
> - pll6: clk at 01c20028 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll6-clk";
> - reg = <0x01c20028 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll6_sata", "pll6_other", "pll6";
> - };
> -
> - pll7: clk at 01c20030 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll3-clk";
> - reg = <0x01c20030 0x4>;
> - clocks = <&osc3M>;
> - clock-output-names = "pll7";
> - };
> -
> - pll7x2: pll7x2_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <1>;
> - clock-mult = <2>;
> - clocks = <&pll7>;
> - clock-output-names = "pll7-2x";
> - };
> -
> - /* dummy is 200M */
> - cpu: cpu at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-cpu-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&osc32k>, <&osc24M>, <&pll1>, <&dummy>;
> - clock-output-names = "cpu";
> - };
> -
> - axi: axi at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-axi-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&cpu>;
> - clock-output-names = "axi";
> - };
> -
> - axi_gates: clk at 01c2005c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-axi-gates-clk";
> - reg = <0x01c2005c 0x4>;
> - clocks = <&axi>;
> - clock-indices = <0>;
> - clock-output-names = "axi_dram";
> - };
> -
> - ahb: ahb at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-ahb-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&axi>;
> - clock-output-names = "ahb";
> - };
> -
> - ahb_gates: clk at 01c20060 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-ahb-gates-clk";
> - reg = <0x01c20060 0x8>;
> - clocks = <&ahb>;
> - clock-indices = <0>, <1>,
> - <2>, <3>,
> - <4>, <5>, <6>,
> - <7>, <8>, <9>,
> - <10>, <11>, <12>,
> - <13>, <14>, <16>,
> - <17>, <18>, <20>,
> - <21>, <22>, <23>,
> - <24>, <25>, <26>,
> - <32>, <33>, <34>,
> - <35>, <36>, <37>,
> - <40>, <41>, <43>,
> - <44>, <45>,
> - <46>, <47>,
> - <50>, <52>;
> - clock-output-names = "ahb_usb0", "ahb_ehci0",
> - "ahb_ohci0", "ahb_ehci1",
> - "ahb_ohci1", "ahb_ss", "ahb_dma",
> - "ahb_bist", "ahb_mmc0", "ahb_mmc1",
> - "ahb_mmc2", "ahb_mmc3", "ahb_ms",
> - "ahb_nand", "ahb_sdram", "ahb_ace",
> - "ahb_emac", "ahb_ts", "ahb_spi0",
> - "ahb_spi1", "ahb_spi2", "ahb_spi3",
> - "ahb_pata", "ahb_sata", "ahb_gps",
> - "ahb_ve", "ahb_tvd", "ahb_tve0",
> - "ahb_tve1", "ahb_lcd0", "ahb_lcd1",
> - "ahb_csi0", "ahb_csi1", "ahb_hdmi",
> - "ahb_de_be0", "ahb_de_be1",
> - "ahb_de_fe0", "ahb_de_fe1",
> - "ahb_mp", "ahb_mali400";
> - };
> -
> - apb0: apb0 at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-apb0-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&ahb>;
> - clock-output-names = "apb0";
> - };
> -
> - apb0_gates: clk at 01c20068 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-apb0-gates-clk";
> - reg = <0x01c20068 0x4>;
> - clocks = <&apb0>;
> - clock-indices = <0>, <1>,
> - <2>, <3>,
> - <5>, <6>,
> - <7>, <10>;
> - clock-output-names = "apb0_codec", "apb0_spdif",
> - "apb0_ac97", "apb0_iis",
> - "apb0_pio", "apb0_ir0",
> - "apb0_ir1", "apb0_keypad";
> - };
> -
> - apb1: clk at 01c20058 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-apb1-clk";
> - reg = <0x01c20058 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
> - clock-output-names = "apb1";
> - };
> -
> - apb1_gates: clk at 01c2006c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-apb1-gates-clk";
> - reg = <0x01c2006c 0x4>;
> - clocks = <&apb1>;
> - clock-indices = <0>, <1>,
> - <2>, <4>,
> - <5>, <6>,
> - <7>, <16>,
> - <17>, <18>,
> - <19>, <20>,
> - <21>, <22>,
> - <23>;
> - clock-output-names = "apb1_i2c0", "apb1_i2c1",
> - "apb1_i2c2", "apb1_can",
> - "apb1_scr", "apb1_ps20",
> - "apb1_ps21", "apb1_uart0",
> - "apb1_uart1", "apb1_uart2",
> - "apb1_uart3", "apb1_uart4",
> - "apb1_uart5", "apb1_uart6",
> - "apb1_uart7";
> - };
> -
> - nand_clk: clk at 01c20080 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20080 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "nand";
> - };
> -
> - ms_clk: clk at 01c20084 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20084 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ms";
> - };
> -
> - mmc0_clk: clk at 01c20088 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20088 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc0",
> - "mmc0_output",
> - "mmc0_sample";
> - };
> -
> - mmc1_clk: clk at 01c2008c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c2008c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc1",
> - "mmc1_output",
> - "mmc1_sample";
> - };
> -
> - mmc2_clk: clk at 01c20090 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20090 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc2",
> - "mmc2_output",
> - "mmc2_sample";
> - };
> -
> - mmc3_clk: clk at 01c20094 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20094 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc3",
> - "mmc3_output",
> - "mmc3_sample";
> - };
> -
> - ts_clk: clk at 01c20098 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20098 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ts";
> - };
> -
> - ss_clk: clk at 01c2009c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c2009c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ss";
> - };
> -
> - spi0_clk: clk at 01c200a0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a0 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi0";
> - };
> -
> - spi1_clk: clk at 01c200a4 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a4 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi1";
> - };
> -
> - spi2_clk: clk at 01c200a8 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a8 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi2";
> - };
> -
> - pata_clk: clk at 01c200ac {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200ac 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "pata";
> - };
> -
> - ir0_clk: clk at 01c200b0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200b0 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ir0";
> - };
> -
> - ir1_clk: clk at 01c200b4 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200b4 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ir1";
> - };
> -
> - spdif_clk: clk at 01c200c0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod1-clk";
> - reg = <0x01c200c0 0x4>;
> - clocks = <&pll2 SUN4I_A10_PLL2_8X>,
> - <&pll2 SUN4I_A10_PLL2_4X>,
> - <&pll2 SUN4I_A10_PLL2_2X>,
> - <&pll2 SUN4I_A10_PLL2_1X>;
> - clock-output-names = "spdif";
> - };
> -
> - usb_clk: clk at 01c200cc {
> - #clock-cells = <1>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun4i-a10-usb-clk";
> - reg = <0x01c200cc 0x4>;
> - clocks = <&pll6 1>;
> - clock-output-names = "usb_ohci0", "usb_ohci1",
> - "usb_phy";
> - };
> -
> - spi3_clk: clk at 01c200d4 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200d4 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi3";
> - };
> -
> - dram_gates: clk at 01c20100 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-dram-gates-clk";
> - reg = <0x01c20100 0x4>;
> - clocks = <&pll5 0>;
> - clock-indices = <0>,
> - <1>, <2>,
> - <3>,
> - <4>,
> - <5>, <6>,
> - <15>,
> - <24>, <25>,
> - <26>, <27>,
> - <28>, <29>;
> - clock-output-names = "dram_ve",
> - "dram_csi0", "dram_csi1",
> - "dram_ts",
> - "dram_tvd",
> - "dram_tve0", "dram_tve1",
> - "dram_output",
> - "dram_de_fe1", "dram_de_fe0",
> - "dram_de_be0", "dram_de_be1",
> - "dram_de_mp", "dram_ace";
> - };
> -
> - de_be0_clk: clk at 01c20104 {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c20104 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-be0";
> - };
> -
> - de_be1_clk: clk at 01c20108 {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c20108 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-be1";
> - };
> -
> - de_fe0_clk: clk at 01c2010c {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c2010c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-fe0";
> - };
> -
> - de_fe1_clk: clk at 01c20110 {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c20110 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-fe1";
> - };
> -
> -
> - tcon0_ch0_clk: clk at 01c20118 {
> - #clock-cells = <0>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> - reg = <0x01c20118 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon0-ch0-sclk";
> -
> - };
> -
> - tcon1_ch0_clk: clk at 01c2011c {
> - #clock-cells = <0>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> - reg = <0x01c2011c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon1-ch0-sclk";
> -
> - };
> -
> - tcon0_ch1_clk: clk at 01c2012c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> - reg = <0x01c2012c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon0-ch1-sclk";
> -
> - };
> -
> - tcon1_ch1_clk: clk at 01c20130 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> - reg = <0x01c20130 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon1-ch1-sclk";
> -
> - };
> -
> - ve_clk: clk at 01c2013c {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-ve-clk";
> - reg = <0x01c2013c 0x4>;
> - clocks = <&pll4>;
> - clock-output-names = "ve";
> - };
> -
> - codec_clk: clk at 01c20140 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-codec-clk";
> - reg = <0x01c20140 0x4>;
> - clocks = <&pll2 SUN4I_A10_PLL2_1X>;
> - clock-output-names = "codec";
> - };
> };
>
> soc at 01c00000 {
> @@ -717,7 +233,7 @@
> compatible = "allwinner,sun4i-a10-dma";
> reg = <0x01c02000 0x1000>;
> interrupts = <27>;
> - clocks = <&ahb_gates 6>;
> + clocks = <&ccu CLK_AHB_DMA>;
> #dma-cells = <2>;
> };
>
> @@ -725,7 +241,7 @@
> compatible = "allwinner,sun4i-a10-nand";
> reg = <0x01c03000 0x1000>;
> interrupts = <37>;
> - clocks = <&ahb_gates 13>, <&nand_clk>;
> + clocks = <&ccu CLK_AHB_NAND>, <&ccu CLK_NAND>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 3>;
> dma-names = "rxtx";
> @@ -738,7 +254,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c05000 0x1000>;
> interrupts = <10>;
> - clocks = <&ahb_gates 20>, <&spi0_clk>;
> + clocks = <&ccu CLK_AHB_SPI0>, <&ccu CLK_SPI0>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 27>,
> <&dma SUN4I_DMA_DEDICATED 26>;
> @@ -752,7 +268,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c06000 0x1000>;
> interrupts = <11>;
> - clocks = <&ahb_gates 21>, <&spi1_clk>;
> + clocks = <&ccu CLK_AHB_SPI1>, <&ccu CLK_SPI1>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 9>,
> <&dma SUN4I_DMA_DEDICATED 8>;
> @@ -766,7 +282,7 @@
> compatible = "allwinner,sun4i-a10-emac";
> reg = <0x01c0b000 0x1000>;
> interrupts = <55>;
> - clocks = <&ahb_gates 17>;
> + clocks = <&ccu CLK_AHB_EMAC>;
> allwinner,sram = <&emac_sram 1>;
> status = "disabled";
> };
> @@ -782,10 +298,10 @@
> mmc0: mmc at 01c0f000 {
> compatible = "allwinner,sun4i-a10-mmc";
> reg = <0x01c0f000 0x1000>;
> - clocks = <&ahb_gates 8>,
> - <&mmc0_clk 0>,
> - <&mmc0_clk 1>,
> - <&mmc0_clk 2>;
> + clocks = <&ccu CLK_AHB_MMC0>,
> + <&ccu CLK_MMC0>,
> + <&ccu CLK_MMC0_OUTPUT>,
> + <&ccu CLK_MMC0_SAMPLE>;
> clock-names = "ahb",
> "mmc",
> "output",
> @@ -799,10 +315,10 @@
> mmc1: mmc at 01c10000 {
> compatible = "allwinner,sun4i-a10-mmc";
> reg = <0x01c10000 0x1000>;
> - clocks = <&ahb_gates 9>,
> - <&mmc1_clk 0>,
> - <&mmc1_clk 1>,
> - <&mmc1_clk 2>;
> + clocks = <&ccu CLK_AHB_MMC1>,
> + <&ccu CLK_MMC1>,
> + <&ccu CLK_MMC1_OUTPUT>,
> + <&ccu CLK_MMC1_SAMPLE>;
> clock-names = "ahb",
> "mmc",
> "output",
> @@ -816,10 +332,10 @@
> mmc2: mmc at 01c11000 {
> compatible = "allwinner,sun4i-a10-mmc";
> reg = <0x01c11000 0x1000>;
> - clocks = <&ahb_gates 10>,
> - <&mmc2_clk 0>,
> - <&mmc2_clk 1>,
> - <&mmc2_clk 2>;
> + clocks = <&ccu CLK_AHB_MMC2>,
> + <&ccu CLK_MMC2>,
> + <&ccu CLK_MMC2_OUTPUT>,
> + <&ccu CLK_MMC2_SAMPLE>;
> clock-names = "ahb",
> "mmc",
> "output",
> @@ -833,10 +349,10 @@
> mmc3: mmc at 01c12000 {
> compatible = "allwinner,sun4i-a10-mmc";
> reg = <0x01c12000 0x1000>;
> - clocks = <&ahb_gates 11>,
> - <&mmc3_clk 0>,
> - <&mmc3_clk 1>,
> - <&mmc3_clk 2>;
> + clocks = <&ccu CLK_AHB_MMC3>,
> + <&ccu CLK_MMC3>,
> + <&ccu CLK_MMC3_OUTPUT>,
> + <&ccu CLK_MMC3_SAMPLE>;
> clock-names = "ahb",
> "mmc",
> "output",
> @@ -850,7 +366,7 @@
> usb_otg: usb at 01c13000 {
> compatible = "allwinner,sun4i-a10-musb";
> reg = <0x01c13000 0x0400>;
> - clocks = <&ahb_gates 0>;
> + clocks = <&ccu CLK_AHB_OTG>;
> interrupts = <38>;
> interrupt-names = "mc";
> phys = <&usbphy 0>;
> @@ -865,9 +381,11 @@
> compatible = "allwinner,sun4i-a10-usb-phy";
> reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
> reg-names = "phy_ctrl", "pmu1", "pmu2";
> - clocks = <&usb_clk 8>;
> + clocks = <&ccu CLK_USB_PHY>;
> clock-names = "usb_phy";
> - resets = <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>;
> + resets = <&ccu RST_USB_PHY0>,
> + <&ccu RST_USB_PHY1>,
> + <&ccu RST_USB_PHY2>;
> reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
> status = "disabled";
> };
> @@ -876,7 +394,7 @@
> compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> reg = <0x01c14000 0x100>;
> interrupts = <39>;
> - clocks = <&ahb_gates 1>;
> + clocks = <&ccu CLK_AHB_EHCI0>;
> phys = <&usbphy 1>;
> phy-names = "usb";
> status = "disabled";
> @@ -886,7 +404,7 @@
> compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> reg = <0x01c14400 0x100>;
> interrupts = <64>;
> - clocks = <&usb_clk 6>, <&ahb_gates 2>;
> + clocks = <&ccu CLK_USB_OHCI0>, <&ccu CLK_AHB_OHCI0>;
> phys = <&usbphy 1>;
> phy-names = "usb";
> status = "disabled";
> @@ -896,7 +414,7 @@
> compatible = "allwinner,sun4i-a10-crypto";
> reg = <0x01c15000 0x1000>;
> interrupts = <86>;
> - clocks = <&ahb_gates 5>, <&ss_clk>;
> + clocks = <&ccu CLK_AHB_SS>, <&ccu CLK_SS>;
> clock-names = "ahb", "mod";
> };
>
> @@ -904,7 +422,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c17000 0x1000>;
> interrupts = <12>;
> - clocks = <&ahb_gates 22>, <&spi2_clk>;
> + clocks = <&ccu CLK_AHB_SPI2>, <&ccu CLK_SPI2>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 29>,
> <&dma SUN4I_DMA_DEDICATED 28>;
> @@ -918,7 +436,8 @@
> compatible = "allwinner,sun4i-a10-ahci";
> reg = <0x01c18000 0x1000>;
> interrupts = <56>;
> - clocks = <&pll6 0>, <&ahb_gates 25>;
> + clocks = <&ccu CLK_PLL_PERIPH_SATA>,
> + <&ccu CLK_AHB_SATA>;
> status = "disabled";
> };
>
> @@ -926,7 +445,7 @@
> compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> reg = <0x01c1c000 0x100>;
> interrupts = <40>;
> - clocks = <&ahb_gates 3>;
> + clocks = <&ccu CLK_AHB_EHCI1>;
> phys = <&usbphy 2>;
> phy-names = "usb";
> status = "disabled";
> @@ -936,7 +455,7 @@
> compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> reg = <0x01c1c400 0x100>;
> interrupts = <65>;
> - clocks = <&usb_clk 7>, <&ahb_gates 4>;
> + clocks = <&ccu CLK_USB_OHCI1>, <&ccu CLK_AHB_OHCI1>;
> phys = <&usbphy 2>;
> phy-names = "usb";
> status = "disabled";
> @@ -946,7 +465,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c1f000 0x1000>;
> interrupts = <50>;
> - clocks = <&ahb_gates 23>, <&spi3_clk>;
> + clocks = <&ccu CLK_AHB_SPI3>, <&ccu CLK_SPI3>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 31>,
> <&dma SUN4I_DMA_DEDICATED 30>;
> @@ -956,6 +475,15 @@
> #size-cells = <0>;
> };
>
> + ccu: clock at 01c20000 {
> + compatible = "allwinner,sun4i-a10-ccu";
> + reg = <0x01c20000 0x400>;
> + clocks = <&osc24M>, <&osc32k>;
> + clock-names = "hosc", "losc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> intc: interrupt-controller at 01c20400 {
> compatible = "allwinner,sun4i-a10-ic";
> reg = <0x01c20400 0x400>;
> @@ -967,7 +495,7 @@
> compatible = "allwinner,sun4i-a10-pinctrl";
> reg = <0x01c20800 0x400>;
> interrupts = <28>;
> - clocks = <&apb0_gates 5>, <&osc24M>, <&osc32k>;
> + clocks = <&ccu CLK_APB0_PIO>, <&osc24M>, <&osc32k>;
> clock-names = "apb", "hosc", "losc";
> gpio-controller;
> interrupt-controller;
> @@ -1145,7 +673,7 @@
> compatible = "allwinner,sun4i-a10-spdif";
> reg = <0x01c21000 0x400>;
> interrupts = <13>;
> - clocks = <&apb0_gates 1>, <&spdif_clk>;
> + clocks = <&ccu CLK_APB0_SPDIF>, <&ccu CLK_SPDIF>;
> clock-names = "apb", "spdif";
> dmas = <&dma SUN4I_DMA_NORMAL 2>,
> <&dma SUN4I_DMA_NORMAL 2>;
> @@ -1155,7 +683,7 @@
>
> ir0: ir at 01c21800 {
> compatible = "allwinner,sun4i-a10-ir";
> - clocks = <&apb0_gates 6>, <&ir0_clk>;
> + clocks = <&ccu CLK_APB0_IR0>, <&ccu CLK_IR0>;
> clock-names = "apb", "ir";
> interrupts = <5>;
> reg = <0x01c21800 0x40>;
> @@ -1164,7 +692,7 @@
>
> ir1: ir at 01c21c00 {
> compatible = "allwinner,sun4i-a10-ir";
> - clocks = <&apb0_gates 7>, <&ir1_clk>;
> + clocks = <&ccu CLK_APB0_IR1>, <&ccu CLK_IR1>;
> clock-names = "apb", "ir";
> interrupts = <6>;
> reg = <0x01c21c00 0x40>;
> @@ -1183,7 +711,7 @@
> compatible = "allwinner,sun4i-a10-codec";
> reg = <0x01c22c00 0x40>;
> interrupts = <30>;
> - clocks = <&apb0_gates 0>, <&codec_clk>;
> + clocks = <&ccu CLK_APB0_CODEC>, <&ccu CLK_CODEC>;
> clock-names = "apb", "codec";
> dmas = <&dma SUN4I_DMA_NORMAL 19>,
> <&dma SUN4I_DMA_NORMAL 19>;
> @@ -1209,7 +737,7 @@
> interrupts = <1>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 16>;
> + clocks = <&ccu CLK_APB1_UART0>;
> status = "disabled";
> };
>
> @@ -1219,7 +747,7 @@
> interrupts = <2>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 17>;
> + clocks = <&ccu CLK_APB1_UART1>;
> status = "disabled";
> };
>
> @@ -1229,7 +757,7 @@
> interrupts = <3>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 18>;
> + clocks = <&ccu CLK_APB1_UART2>;
> status = "disabled";
> };
>
> @@ -1239,7 +767,7 @@
> interrupts = <4>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 19>;
> + clocks = <&ccu CLK_APB1_UART3>;
> status = "disabled";
> };
>
> @@ -1249,7 +777,7 @@
> interrupts = <17>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 20>;
> + clocks = <&ccu CLK_APB1_UART4>;
> status = "disabled";
> };
>
> @@ -1259,7 +787,7 @@
> interrupts = <18>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 21>;
> + clocks = <&ccu CLK_APB1_UART5>;
> status = "disabled";
> };
>
> @@ -1269,7 +797,7 @@
> interrupts = <19>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 22>;
> + clocks = <&ccu CLK_APB1_UART6>;
> status = "disabled";
> };
>
> @@ -1279,7 +807,7 @@
> interrupts = <20>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 23>;
> + clocks = <&ccu CLK_APB1_UART7>;
> status = "disabled";
> };
>
> @@ -1287,7 +815,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2ac00 0x400>;
> interrupts = <7>;
> - clocks = <&apb1_gates 0>;
> + clocks = <&ccu CLK_APB1_I2C0>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1297,7 +825,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2b000 0x400>;
> interrupts = <8>;
> - clocks = <&apb1_gates 1>;
> + clocks = <&ccu CLK_APB1_I2C1>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1307,7 +835,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2b400 0x400>;
> interrupts = <9>;
> - clocks = <&apb1_gates 2>;
> + clocks = <&ccu CLK_APB1_I2C2>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1317,7 +845,7 @@
> compatible = "allwinner,sun4i-a10-ps2";
> reg = <0x01c2a000 0x400>;
> interrupts = <62>;
> - clocks = <&apb1_gates 6>;
> + clocks = <&ccu CLK_APB1_PS20>;
> status = "disabled";
> };
>
> @@ -1325,7 +853,7 @@
> compatible = "allwinner,sun4i-a10-ps2";
> reg = <0x01c2a400 0x400>;
> interrupts = <63>;
> - clocks = <&apb1_gates 7>;
> + clocks = <&ccu CLK_APB1_PS21>;
> status = "disabled";
> };
> };
> --
> git-series 0.9.1
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] phy: rockchip-typec: Try to turn the PHY on several times
From: Douglas Anderson @ 2017-12-11 21:45 UTC (permalink / raw)
To: linux-arm-kernel
Bind / unbind stress testing of the USB controller on rk3399 found
that we'd often end up with lots of failures that looked like this:
phy phy-ff800000.phy.9: phy poweron failed --> -110
dwc3 fe900000.dwc3: failed to initialize core
dwc3: probe of fe900000.dwc3 failed with error -110
Those errors were sometimes seen at bootup too, in which case USB
peripherals wouldn't work until unplugged and re-plugged in.
I spent some time trying to figure out why the PHY was failing to
power on but I wasn't able to. Possibly this has to do with the fact
that the PHY docs say that the USB controller "needs to be held in
reset to hold pipe power state in P2 before initializing the Type C
PHY" but that doesn't appear to be easy to do with the dwc3 driver
today. Messing around with the ordering of the reset vs. the PHY
initialization in the dwc3 driver didn't seem to fix things.
I did, however, find that if I simply retry the power on it seems to
have a good chance of working. So let's add some retries. I ran a
pretty tight bind/unbind loop overnight. When I did so, I found that
I need to retry between 1% and 2% of the time. Overnight I found only
a small handful of times where I needed 2 retries. I never found a
case where I needed 3 retries.
I'm completely aware of the fact that this is quite an ugly hack and I
wish I didn't have to resort to it, but I have no other real idea how
to make this hardware reliable. If Rockchip in the future can come up
with a solution we can always revert this hack. Until then, let's at
least have something that works.
This patch is tested atop Enric's latest dwc3 patch series ending at:
https://patchwork.kernel.org/patch/10095527/
...but it could be applied independently of that series without any
bad effects.
For some more details on this bug, you can refer to:
https://bugs.chromium.org/p/chromium/issues/detail?id=783464
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/phy/rockchip/phy-rockchip-typec.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c
index ee85fa0ca4b0..5c2157156ce1 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -349,6 +349,8 @@
#define MODE_DFP_USB BIT(1)
#define MODE_DFP_DP BIT(2)
+#define POWER_ON_TRIES 5
+
struct usb3phy_reg {
u32 offset;
u32 enable_bit;
@@ -818,9 +820,8 @@ static int tcphy_get_mode(struct rockchip_typec_phy *tcphy)
return mode;
}
-static int rockchip_usb3_phy_power_on(struct phy *phy)
+static int _rockchip_usb3_phy_power_on(struct rockchip_typec_phy *tcphy)
{
- struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
struct rockchip_usb3phy_port_cfg *cfg = &tcphy->port_cfgs;
const struct usb3phy_reg *reg = &cfg->pipe_status;
int timeout, new_mode, ret = 0;
@@ -867,6 +868,25 @@ static int rockchip_usb3_phy_power_on(struct phy *phy)
return ret;
}
+static int rockchip_usb3_phy_power_on(struct phy *phy)
+{
+ struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
+ int ret;
+ int tries;
+
+ for (tries = 0; tries < POWER_ON_TRIES; tries++) {
+ ret = _rockchip_usb3_phy_power_on(tcphy);
+ if (!ret)
+ break;
+ }
+
+ if (tries && !ret)
+ dev_info(tcphy->dev, "Needed %d loops to turn on\n", tries);
+
+ return ret;
+}
+
+
static int rockchip_usb3_phy_power_off(struct phy *phy)
{
struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
--
2.15.1.424.g9478a66081-goog
^ permalink raw reply related
* [PATCH v4 5/5] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
From: Lukasz Majewski @ 2017-12-11 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <SN1PR0101MB156532C13ABBAE280B3754CED0370@SN1PR0101MB1565.prod.exchangelabs.com>
Hi Hartley,
> On Thursday, November 30, 2017 4:52 PM, Lukasz Majewski wrote:
> >
> > The BK3 board is a derivative of the ts72xx reference design.
>
> Lukasz,
>
> I was just reviewing the other TS-72xx boards and noticed this:
>
> <snip>
>
> > +/* BK3 specific defines */
> > +#define BK3_CPLDVER_PHYS_BASE 0x23400000
> > +#define BK3_CPLDVER_VIRT_BASE 0xfebfd000
> > +#define BK3_CPLDVER_SIZE 0x00001000
> > +
>
> <snip>
>
> > +static struct map_desc bk3_io_desc[] __initdata = {
> > + {
> > + .virtual = BK3_CPLDVER_VIRT_BASE,
> > + .pfn =
> > __phys_to_pfn(BK3_CPLDVER_PHYS_BASE),
> > + .length = BK3_CPLDVER_SIZE,
> > + .type = MT_DEVICE,
> > + }
> > +};
> > +
>
> This register appears to be common to all the TS-72xx boards.
The CPLD was used on the reference ts-72xx boards, but support for it
seems to not be present in the mainline kernel.
Do you have a ts72xx board with CPLD embedded? Is any of your design
using it?
My another concern - is it safe to perform IO mapping on memory regions
which are not used / specified? When I do a single ts72xx mapping - for
all boards - then we may end up with some mappings which are not needed.
With the code as it is - I only map regions which are already used on
relevant boards.
>
> I don't think Arnd has pulled the series yet. Would you mind renaming
> the defines and rebasing this patch?
If needed I can resend the patch series, or prepare a single fix patch.
No problem.
> The BK3 board and other TS-72xx
> boards can then have a common .map_io.
>
> Thanks,
> Hartley
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171211/0cfc9f29/attachment.sig>
^ permalink raw reply
* [PATCH 02/12] mtd: nand: add reworked Marvell NAND controller driver
From: Miquel RAYNAL @ 2017-12-11 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211180511.1d734b37@bbrezillon>
On Mon, 11 Dec 2017 18:05:11 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Mon, 11 Dec 2017 17:55:06 +0100
> Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:
>
> > On Mon, 11 Dec 2017 13:27:30 -0300
> > Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
> >
> > > On 7 December 2017 at 17:18, Miquel Raynal
> > > <miquel.raynal@free-electrons.com> wrote:
> > > > Add marvell_nand driver which aims at replacing the existing
> > > > pxa3xx_nand driver.
> > > >
> > > > The new driver intends to be easier to understand and follows
> > > > the brand new NAND framework rules by implementing hooks for
> > > > every pattern the controller might support and referencing them
> > > > inside a parser object that will be given to the core at each
> > > > ->exec_op() call.
> > > >
> > > > Raw accessors are implemented, useful to test/debug
> > > > memory/filesystem corruptions. Userspace binaries contained in
> > > > the mtd-utils package may now be used and their output trusted.
> > > >
> > > > Timings may not be kept from the bootloader anymore, the timings
> > > > used for instance in U-Boot were not optimal and it supposed to
> > > > have NAND support (and initialized) in the bootloader.
> > > >
> > > > Thanks to the improved timings, implementation of ONFI mode 5
> > > > support (with EDO managed by adding a delay on data sampling),
> > > > merging the commands together and optimizing writes in the
> > > > command registers, the new driver may achieve faster
> > > > throughputs in both directions. Measurements show an
> > > > improvement of about +23% read throughput and +24% write
> > > > throughput. These measurements have been done with an
> > > > Armada-385-DB-AP (4kiB NAND pages forced in 4-bit strength BCH
> > > > ECC correction) using the userspace tool 'flash_speed' from the
> > > > MTD test suite.
> > > >
> > > > Besides these important topics, the new driver addresses several
> > > > unsolved known issues in the old driver which:
> > > > - did not work with ECC soft neither with ECC none ;
> > > > - relied on naked read/write (which is unchanged) while the
> > > > NFCv1 embedded in the pxa3xx platforms do not implement it, so
> > > > several NAND commands did not actually ever work without any
> > > > notice (like reading the ONFI PARAM_PAGE or SET/GET_FEATURES) ;
> > > > - wrote the OOB data correctly, but was not able to read it
> > > > correctly past the first OOB data chunk ;
> > > > - did not displayed ECC bytes ;
> > > > - used device tree bindings that did not allow more than one
> > > > NAND chip, and did not allow to choose the correct chip select
> > > > if not incrementing from 0. Plus, the Ready/Busy line used had
> > > > to be 0.
> > > >
> > > > Old device tree bindings are still supported but deprecated. A
> > > > more hierarchical view has to be used to keep the controller
> > > > and the NAND chip structures clearly separated both inside the
> > > > device tree and also in the driver code.
> > > >
> > >
> > > So, is this driver fully compatible with the current pxa3xx-nand
> > > driver?
> >
> > It should be!
> >
> > >
> > > Have you tested with U-Boot's driver (based on the pxa3xx-nand)?
> > >
> > > I recally some subtle issues with the fact that U-Boot and Linux
> > > had to agree about the BBT format.
> >
> > I kept the pxa3xx_nand driver BBT format.
> >
> > This is something I mistakenly omitted from the commit message:
> >
> > There are 5 supported layouts in the driver (the same as withing the
> > pxa3xx_nand driver):
> > 1/ Page: 512B, strength 1b/512B (hamming)
> > 2/ Page: 2kiB, strength 4b/2kiB (hamming)
> > 3/ page: 2kiB, strength 16b/2kiB (BCH)
> > 4/ page: 4kiB, strength 16b/2kiB (BCH)
> > 5/ page: 4kiB, strength 32b/2kiB (BCH)
>
> Are you sure of #5? I thought the engine was only capable of modifying
> the ECC block size, not the strength. If this is the case, then mode
> #5 is actually 16b/1024kiB.
You are right, #5 you actually be:
5/ page: 4kiB, strength 16b/1kiB (BCH)
Thanks for pointing it,
Miqu?l
>
> >
> > Layout 2 has been tested with CM_X300 compulab module (PXA SoC) with
> > and without DMA.
> > Layout 4 has been tested with an Armada 385 db, an Armada 7040 DB
> > and an Armada 8040 DB.
> > Layout 5 has been tested with an Armada 398 db.
> >
> > Layout 1 has been tested with the Armada 385 db with some hacks.
> > Layout 3 has been tested with the Armada 385 db with some other
> > hacks, that is why I am concerned about the other thread on the MTD
> > mailing list "wait timeout when scanning for BB" where a 2kiB page
> > with 16b/2048B strength is in use.
> >
> > Regards,
> > Miqu?l
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/1] tty: serial: imx: allow breaks to be received when using dma
From: Troy Kisky @ 2017-12-11 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a3f0140a-92bb-ed59-ee79-971385634d4d@boundarydevices.com>
On 10/20/2017 3:17 PM, Troy Kisky wrote:
> On 10/20/2017 3:13 PM, Troy Kisky wrote:
>> This allows me to login after sending a break when service
>> serial-getty at ttymxc0.service is running
>>
>> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
>> ---
>> drivers/tty/serial/imx.c | 20 +++++++++++++-------
>> 1 file changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>> index 506fcd742b47..39033f460a24 100644
>> --- a/drivers/tty/serial/imx.c
>> +++ b/drivers/tty/serial/imx.c
>> @@ -934,7 +934,6 @@ static void dma_rx_callback(void *data)
>> status = dmaengine_tx_status(chan, (dma_cookie_t)0, &state);
>>
>> if (status == DMA_ERROR) {
>> - dev_err(sport->port.dev, "DMA transaction error.\n");
>> clear_rx_errors(sport);
>> return;
>> }
>> @@ -1035,6 +1034,7 @@ static int start_rx_dma(struct imx_port *sport)
>>
>> static void clear_rx_errors(struct imx_port *sport)
>> {
>> + struct tty_port *port = &sport->port.state->port;
>> unsigned int status_usr1, status_usr2;
>>
>> status_usr1 = readl(sport->port.membase + USR1);
>> @@ -1043,12 +1043,18 @@ static void clear_rx_errors(struct imx_port *sport)
>> if (status_usr2 & USR2_BRCD) {
>> sport->port.icount.brk++;
>> writel(USR2_BRCD, sport->port.membase + USR2);
>> - } else if (status_usr1 & USR1_FRAMERR) {
>> - sport->port.icount.frame++;
>> - writel(USR1_FRAMERR, sport->port.membase + USR1);
>> - } else if (status_usr1 & USR1_PARITYERR) {
>> - sport->port.icount.parity++;
>> - writel(USR1_PARITYERR, sport->port.membase + USR1);
>> + if (tty_insert_flip_char(port, 0, TTY_BREAK) == 0)
>> + sport->port.icount.buf_overrun++;
>> + tty_flip_buffer_push(port);
>> + } else {
>> + dev_err(sport->port.dev, "DMA transaction error.\n");
>> + if (status_usr1 & USR1_FRAMERR) {
>> + sport->port.icount.frame++;
>> + writel(USR1_FRAMERR, sport->port.membase + USR1);
>> + } else if (status_usr1 & USR1_PARITYERR) {
>> + sport->port.icount.parity++;
>> + writel(USR1_PARITYERR, sport->port.membase + USR1);
>> + }
>> }
>>
>> if (status_usr2 & USR2_ORE) {
>>
>
>
>
> Does this need to use
> spin_lock_irqsave(&sport->port.lock, flags);
>
>
> I would have, but dma_rx_callback doesn't.
>
> BR
> Troy
>
>
I think the path is fine as is. Should I send a rebased version ?
Thanks
Troy
^ permalink raw reply
* [PATCH v7 3/8] KVM: arm/arm64: Don't cache the timer IRQ level
From: Auger Eric @ 2017-12-11 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-4-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> The timer was modeled after a strict idea of modelling an interrupt line
> level in software, meaning that only transitions in the level needed to
> be reported to the VGIC. This works well for the timer, because the
> arch timer code is in complete control of the device and can track the
> transitions of the line.
>
> However, as we are about to support using the HW bit in the VGIC not
> just for the timer, but also for VFIO which cannot track transitions of
> the interrupt line, we have to decide on an interface for level
> triggered mapped interrupts to the GIC, which both the timer and VFIO
> can use.
>
> VFIO only sees an asserting transition of the physical interrupt line,
> and tells the VGIC when that happens. That means that part of the
> interrupt flow is offloaded to the hardware.
>
> To use the same interface for VFIO devices and the timer, we therefore
> have to change the timer (we cannot change VFIO because it doesn't know
> the details of the device it is assigning to a VM).
>
> Luckily, changing the timer is simple, we just need to stop 'caching'
> the line level, but instead let the VGIC know the state of the timer
> every time there is a potential change in the line level, and when the
> line level should be asserted from the timer ISR. The VGIC can ignore
> extra notifications using its validate mechanism.
I was confused by the fact we say we stop caching the line level but
vtimer->irq.level still exists, is updated in the vtimer host ISR and
kvm_timer_update_state() and read in many places.
I feel difficult to figure out if each time we use the vtimer->irq.level
value it is safe to use it.
Also for the validate() to succeed we need the vgic irq->line_level to
to be 0. I understand this is properly handled for mapped level irqs in
next patch which does that on the populate_lr. However I currently fail
to understand why the timer level sensitive mapped IRQ does not require
the next patch to work.
Thanks
Eric
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/arch_timer.c | 20 +++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 4151250ce8da..dd5aca05c500 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -99,11 +99,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> }
> vtimer = vcpu_vtimer(vcpu);
>
> - if (!vtimer->irq.level) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - if (kvm_timer_irq_can_fire(vtimer))
> - kvm_timer_update_irq(vcpu, true, vtimer);
> - }
> + vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> + if (kvm_timer_irq_can_fire(vtimer))
> + kvm_timer_update_irq(vcpu, true, vtimer);
>
> if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
> kvm_vtimer_update_mask_user(vcpu);
> @@ -324,12 +322,20 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
> + bool level;
>
> if (unlikely(!timer->enabled))
> return;
>
> - if (kvm_timer_should_fire(vtimer) != vtimer->irq.level)
> - kvm_timer_update_irq(vcpu, !vtimer->irq.level, vtimer);
> + /*
> + * The vtimer virtual interrupt is a 'mapped' interrupt, meaning part
> + * of its lifecycle is offloaded to the hardware, and we therefore may
> + * not have lowered the irq.level value before having to signal a new
> + * interrupt, but have to signal an interrupt every time the level is
> + * asserted.
> + */
> + level = kvm_timer_should_fire(vtimer);
> + kvm_timer_update_irq(vcpu, level, vtimer);
>
> if (kvm_timer_should_fire(ptimer) != ptimer->irq.level)
> kvm_timer_update_irq(vcpu, !ptimer->irq.level, ptimer);
>
^ permalink raw reply
* [PATCH v7 0/8] Handle forwarded level-triggered interrupts
From: Auger Eric @ 2017-12-11 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-1-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> This series is an alternative approach to Eric Auger's direct EOI setup
> patches [1] in terms of the KVM VGIC support.
>
> The idea is to maintain existing semantics for the VGIC for mapped
> level-triggered IRQs and also support the timer using mapped IRQs with
> the same VGIC support as VFIO interrupts.
>
> Based on v4.15-rc1.
>
> Also available at:
> git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git level-mapped-v7
>
> Changes since v6:
> - Removed double semi-colon
> - Changed another confusing conditional in patch 6
> - Fixed typos in commit message and comments
>
> Changes since v5:
> - Rebased on v4.15-rc1
> - Changed comment on preemption code as suggested by Andre
> - Fixed white space and confusing conditionals as suggested by Drew
>
> Changes since v4:
> - Rebased on the timer optimization series merged in the v4.15 merge
> window, which caused a fair amount of modifications to patch 3.
> - Added a static key to disable the sync operations when no VMs are
> using userspace irqchips to further optimize the performance
> - Fixed extra semicolon in vgic-mmio.c
> - Added commentary as requested during review
> - Dropped what was patch 4, because it was merged as part of GICv4
> support.
> - Factored out the VGIC input level function change as separate patch
> (helps bisect and debugging), before providing a function for the
> timer.
>
> Changes since v3:
> - Added a number of patches and moved patches around a bit.
> - Check for uaccesses in the mmio handler functions
> - Fixed bugs in the mmio handler functions
>
> Changes since v2:
> - Removed patch 5 from v2 and integrating the changes in what's now
> patch 5 to make it easier to reuse code when adding VFIO integration.
> - Changed the virtual distributor MMIO handling to use the
> pending_latch and more closely match the semantics of SPENDR and
> CPENDR for both level and edge mapped interrupts.
>
> Changes since v1:
> - Added necessary changes to the timer (Patch 1)
> - Added handling of guest MMIO accesses to the virtual distributor
> (Patch 4)
> - Addressed Marc's comments from the initial RFC (mostly renames)
>
> Thanks,
> -Christoffer
>
> [1]: https://lists.cs.columbia.edu/pipermail/kvmarm/2017-June/026072.html
>
> Christoffer Dall (8):
> KVM: arm/arm64: Remove redundant preemptible checks
> KVM: arm/arm64: Factor out functionality to get vgic mmio
> requester_vcpu
> KVM: arm/arm64: Don't cache the timer IRQ level
> KVM: arm/arm64: vgic: Support level-triggered mapped interrupts
> KVM: arm/arm64: Support a vgic interrupt line level sample function
> KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs
> KVM: arm/arm64: Provide a get_input_level for the arch timer
> KVM: arm/arm64: Avoid work when userspace iqchips are not used
>
> include/kvm/arm_arch_timer.h | 2 +
> include/kvm/arm_vgic.h | 13 ++++-
> virt/kvm/arm/arch_timer.c | 105 +++++++++++++++++++++-----------------
> virt/kvm/arm/arm.c | 2 -
> virt/kvm/arm/vgic/vgic-mmio.c | 115 ++++++++++++++++++++++++++++++++++--------
> virt/kvm/arm/vgic/vgic-v2.c | 29 +++++++++++
> virt/kvm/arm/vgic/vgic-v3.c | 29 +++++++++++
> virt/kvm/arm/vgic/vgic.c | 42 +++++++++++++--
> virt/kvm/arm/vgic/vgic.h | 8 +++
> 9 files changed, 270 insertions(+), 75 deletions(-)
>
I tested the series with AMD xgbe assignment using Direct EOI and I
don't see any regression. However most interesting assigned IRQs - DMA
related - are edge sensitive ones.
Tested-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
^ permalink raw reply
* [PATCH 3/3] ARM: dts: bcm283x: Define polarity of per-cpu interrupts
From: Stefan Wahren @ 2017-12-11 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513024752-11246-1-git-send-email-stefan.wahren@i2se.com>
This patch define the polarity of the per-cpu interrupts on BCM2836
and BCM2837 in order to avoid the warnings from ARM arch timer code:
arch_timer: WARNING: Invalid trigger for IRQ19, assuming level low
arch_timer: WARNING: Please fix your firmware
arch_timer: cp15 timer(s) running at 19.20MHz (virt).
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
arch/arm/boot/dts/bcm2836.dtsi | 14 +++++++-------
arch/arm/boot/dts/bcm2837.dtsi | 12 ++++++------
arch/arm/boot/dts/bcm283x.dtsi | 1 +
3 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi
index 61e1580..1dfd764 100644
--- a/arch/arm/boot/dts/bcm2836.dtsi
+++ b/arch/arm/boot/dts/bcm2836.dtsi
@@ -13,24 +13,24 @@
compatible = "brcm,bcm2836-l1-intc";
reg = <0x40000000 0x100>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
interrupt-parent = <&local_intc>;
};
arm-pmu {
compatible = "arm,cortex-a7-pmu";
interrupt-parent = <&local_intc>;
- interrupts = <9>;
+ interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
};
};
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&local_intc>;
- interrupts = <0>, // PHYS_SECURE_PPI
- <1>, // PHYS_NONSECURE_PPI
- <3>, // VIRT_PPI
- <2>; // HYP_PPI
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>, // PHYS_SECURE_PPI
+ <1 IRQ_TYPE_LEVEL_HIGH>, // PHYS_NONSECURE_PPI
+ <3 IRQ_TYPE_LEVEL_HIGH>, // VIRT_PPI
+ <2 IRQ_TYPE_LEVEL_HIGH>; // HYP_PPI
always-on;
};
@@ -76,7 +76,7 @@
compatible = "brcm,bcm2836-armctrl-ic";
reg = <0x7e00b200 0x200>;
interrupt-parent = <&local_intc>;
- interrupts = <8>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
};
&cpu_thermal {
diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi
index bc1cca5..efa7d33 100644
--- a/arch/arm/boot/dts/bcm2837.dtsi
+++ b/arch/arm/boot/dts/bcm2837.dtsi
@@ -12,7 +12,7 @@
compatible = "brcm,bcm2836-l1-intc";
reg = <0x40000000 0x100>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
interrupt-parent = <&local_intc>;
};
};
@@ -20,10 +20,10 @@
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&local_intc>;
- interrupts = <0>, // PHYS_SECURE_PPI
- <1>, // PHYS_NONSECURE_PPI
- <3>, // VIRT_PPI
- <2>; // HYP_PPI
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>, // PHYS_SECURE_PPI
+ <1 IRQ_TYPE_LEVEL_HIGH>, // PHYS_NONSECURE_PPI
+ <3 IRQ_TYPE_LEVEL_HIGH>, // VIRT_PPI
+ <2 IRQ_TYPE_LEVEL_HIGH>; // HYP_PPI
always-on;
};
@@ -73,7 +73,7 @@
compatible = "brcm,bcm2836-armctrl-ic";
reg = <0x7e00b200 0x200>;
interrupt-parent = <&local_intc>;
- interrupts = <8>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
};
&cpu_thermal {
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index e08203c..0d43bd4 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -2,6 +2,7 @@
#include <dt-bindings/clock/bcm2835.h>
#include <dt-bindings/clock/bcm2835-aux.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
/* firmware-provided startup stubs live here, where the secondary CPUs are
* spinning.
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] irqchip: irq-bcm2836: add support for DT interrupt polarity
From: Stefan Wahren @ 2017-12-11 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513024752-11246-1-git-send-email-stefan.wahren@i2se.com>
In order to properly define the polarity of the per-cpu interrupts,
we need to support for a second property cell. But this must be
optional to keep backward compatibility with old DT blobs.
Suggested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/irqchip/irq-bcm2836.c | 46 ++++++++++++++++++++++++++-----------------
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 667b9e1..dfe4a46 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -98,13 +98,35 @@ static struct irq_chip bcm2836_arm_irqchip_gpu = {
.irq_unmask = bcm2836_arm_irqchip_unmask_gpu_irq,
};
-static void bcm2836_arm_irqchip_register_irq(int hwirq, struct irq_chip *chip)
-{
- int irq = irq_create_mapping(intc.domain, hwirq);
+static int bcm2836_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+ struct irq_chip *chip;
+
+ switch (hw) {
+ case LOCAL_IRQ_CNTPSIRQ:
+ case LOCAL_IRQ_CNTPNSIRQ:
+ case LOCAL_IRQ_CNTHPIRQ:
+ case LOCAL_IRQ_CNTVIRQ:
+ chip = &bcm2836_arm_irqchip_timer;
+ break;
+ case LOCAL_IRQ_GPU_FAST:
+ chip = &bcm2836_arm_irqchip_gpu;
+ break;
+ case LOCAL_IRQ_PMU_FAST:
+ chip = &bcm2836_arm_irqchip_pmu;
+ break;
+ default:
+ pr_warn_once("Unexpected hw irq: %lu\n", hw);
+ return -EINVAL;
+ }
irq_set_percpu_devid(irq);
- irq_set_chip_and_handler(irq, chip, handle_percpu_devid_irq);
+ irq_domain_set_info(d, irq, hw, chip, d->host_data,
+ handle_percpu_devid_irq, NULL, NULL);
irq_set_status_flags(irq, IRQ_NOAUTOEN);
+
+ return 0;
}
static void
@@ -165,7 +187,8 @@ static int bcm2836_cpu_dying(unsigned int cpu)
#endif
static const struct irq_domain_ops bcm2836_arm_irqchip_intc_ops = {
- .xlate = irq_domain_xlate_onecell
+ .xlate = irq_domain_xlate_onetwocell,
+ .map = bcm2836_map,
};
static void
@@ -218,19 +241,6 @@ static int __init bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
if (!intc.domain)
panic("%pOF: unable to create IRQ domain\n", node);
- bcm2836_arm_irqchip_register_irq(LOCAL_IRQ_CNTPSIRQ,
- &bcm2836_arm_irqchip_timer);
- bcm2836_arm_irqchip_register_irq(LOCAL_IRQ_CNTPNSIRQ,
- &bcm2836_arm_irqchip_timer);
- bcm2836_arm_irqchip_register_irq(LOCAL_IRQ_CNTHPIRQ,
- &bcm2836_arm_irqchip_timer);
- bcm2836_arm_irqchip_register_irq(LOCAL_IRQ_CNTVIRQ,
- &bcm2836_arm_irqchip_timer);
- bcm2836_arm_irqchip_register_irq(LOCAL_IRQ_GPU_FAST,
- &bcm2836_arm_irqchip_gpu);
- bcm2836_arm_irqchip_register_irq(LOCAL_IRQ_PMU_FAST,
- &bcm2836_arm_irqchip_pmu);
-
bcm2836_arm_irqchip_smp_init();
set_handle_irq(bcm2836_arm_irqchip_handle_irq);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: bcm2836-l1-intc: add interrupt polarity support
From: Stefan Wahren @ 2017-12-11 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513024752-11246-1-git-send-email-stefan.wahren@i2se.com>
This increases the interrupt cells for the 1st level interrupt controller
binding in order to describe the polarity like on the other ARM platforms.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
.../devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
index f320dcd..8ced169 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
@@ -12,7 +12,7 @@ Required properties:
registers
- interrupt-controller: Identifies the node as an interrupt controller
- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1
+ interrupt source. The value shall be 2
Please refer to interrupts.txt in this directory for details of the common
Interrupt Controllers bindings used by client devices.
@@ -32,6 +32,6 @@ local_intc: local_intc {
compatible = "brcm,bcm2836-l1-intc";
reg = <0x40000000 0x100>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
interrupt-parent = <&local_intc>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] irqchip: irq-bcm2836: add support for DT interrupt polarity
From: Stefan Wahren @ 2017-12-11 20:39 UTC (permalink / raw)
To: linux-arm-kernel
This patch series implements DT polarity support for the 1st level interrupt
controller.
Stefan Wahren (3):
dt-bindings: bcm2836-l1-intc: add interrupt polarity support
irqchip: irq-bcm2836: add support for DT interrupt polarity
ARM: dts: bcm283x: Define polarity of per-cpu interrupts
.../interrupt-controller/brcm,bcm2836-l1-intc.txt | 4 +-
arch/arm/boot/dts/bcm2836.dtsi | 14 +++----
arch/arm/boot/dts/bcm2837.dtsi | 12 +++---
arch/arm/boot/dts/bcm283x.dtsi | 1 +
drivers/irqchip/irq-bcm2836.c | 46 +++++++++++++---------
5 files changed, 44 insertions(+), 33 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Corentin Labbe @ 2017-12-11 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211075001.6100-1-mylene.josserand@free-electrons.com>
On Mon, Dec 11, 2017 at 08:49:57AM +0100, Myl?ne Josserand wrote:
> Hello everyone,
>
> This series adds SMP support for Allwinner Sun8i-a83t
> with MCPM (Multi-Cluster Power Management).
> Series information:
> - Based on last linux-next (next-20171211)
> - Had dependencies on Chen Yu's patch that add MCPM
> support:
> https://patchwork.kernel.org/patch/6402801/
>
> Patch 01: Convert the mcpm driver (initially for A80) to be able
> to use it for A83T. This SoC has a bit flip that needs to be handled.
> Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg) needed
> for MCPM.
> Patch 03: Add CCI-400 node for a83t.
> Patch 04: Fix the use of virtual timers that hangs the kernel in
> case of SMP support.
>
> If you have any remarks/questions, let me know.
> Thank you in advance,
> Myl?ne
>
Hello
As we discussed in private, Chen Yu's patch should be added in your series.
Furthermore, MCPM is not automaticaly selected via imply.
With all patchs I hit a bug:
[ 0.898668] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
[ 0.911162] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
[ 0.917776] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
[ 0.925418] Hardware name: Allwinner sun8i Family
[ 0.930118] Backtrace:
[ 0.932596] [<c010cc50>] (dump_backtrace) from [<c010cf0c>] (show_stack+0x18/0x1c)
[ 0.940158] r7:c0b261e4 r6:60000013 r5:00000000 r4:c0b51958
[ 0.945820] [<c010cef4>] (show_stack) from [<c06baccc>] (dump_stack+0x8c/0xa0)
[ 0.953045] [<c06bac40>] (dump_stack) from [<c0149d40>] (___might_sleep+0x150/0x170)
[ 0.960779] r7:c0b261e4 r6:00000000 r5:000000ee r4:ee844000
[ 0.966437] [<c0149bf0>] (___might_sleep) from [<c0149dc8>] (__might_sleep+0x68/0xa0)
[ 0.974253] r4:c0861690
[ 0.976796] [<c0149d60>] (__might_sleep) from [<c06d2918>] (mutex_lock+0x24/0x68)
[ 0.984269] r6:c0892f6c r5:ffffffff r4:c0b1bb24
[ 0.988891] [<c06d28f4>] (mutex_lock) from [<c01ccb6c>] (perf_pmu_register+0x24/0x3e4)
[ 0.996795] r5:ffffffff r4:ee98b014
[ 1.000375] [<c01ccb48>] (perf_pmu_register) from [<c03efabc>] (cci_pmu_probe+0x340/0x484)
[ 1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4 r6:c0b26240 r5:eea19000
[ 1.016447] r4:ee98b010
[ 1.018989] [<c03ef77c>] (cci_pmu_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
[ 1.027158] r10:00000000 r9:c0b2610c r8:00000000 r7:fffffdfb r6:c0b2610c r5:ffffffed
[ 1.034974] r4:eea19010
[ 1.037511] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
[ 1.046371] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea19010
[ 1.052026] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
[ 1.061062] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea19010 r5:ee845ac0
[ 1.068879] r4:c0b2610c r3:00000000
[ 1.072454] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
[ 1.081228] r7:00000001 r6:c045cb24 r5:ee845ac0 r4:00000000
[ 1.086883] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
[ 1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010
[ 1.099750] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
[ 1.108263] r7:c0b0a4c8 r6:c0b3e848 r5:eea19010 r4:eea19018
[ 1.113919] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
[ 1.122523] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
[ 1.130429] r7:c0b0a4c8 r6:eea19010 r5:eea18a10 r4:eea19018
[ 1.136089] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
[ 1.143564] r10:00000000 r9:00000000 r8:00000000 r7:eedf21a4 r6:eea18a10 r5:00000000
[ 1.151380] r4:eea19000
[ 1.153915] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
[ 1.163210] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
[ 1.173372] r9:00000000 r8:00000000 r7:00000001 r6:00000000 r5:eedf2154 r4:00000000
[ 1.181107] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
[ 1.190229] r10:00000001 r9:eea18a10 r8:00000000 r7:00000000 r6:00000000 r5:eedf1d04
[ 1.198045] r4:eedf2154
[ 1.200580] [<c0583300>] (of_platform_populate) from [<c03ef2a8>] (cci_platform_probe+0x3c/0x54)
[ 1.209356] r10:00000000 r9:c0b26168 r8:00000000 r7:fffffdfb r6:c0b26168 r5:ffffffed
[ 1.217172] r4:eea18a00
[ 1.219708] [<c03ef26c>] (cci_platform_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
[ 1.228306] r5:ffffffed r4:eea18a10
[ 1.231881] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
[ 1.240742] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea18a10
[ 1.246397] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
[ 1.255433] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea18a10 r5:ee845ce8
[ 1.263250] r4:c0b26168 r3:00000000
[ 1.266825] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
[ 1.275598] r7:00000001 r6:c045cb24 r5:ee845ce8 r4:00000000
[ 1.281253] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
[ 1.289506] r6:c0b3e848 r5:eea18a44 r4:eea18a10
[ 1.294120] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
[ 1.302633] r7:c0b0a4c8 r6:c0b3e848 r5:eea18a10 r4:eea18a18
[ 1.308288] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
[ 1.316890] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
[ 1.324796] r7:c0b0a4c8 r6:eea18a10 r5:ee993810 r4:eea18a18
[ 1.330450] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
[ 1.337926] r10:00000000 r9:c07759d8 r8:00000000 r7:eedf1d54 r6:ee993810 r5:00000000
[ 1.345743] r4:eea18a00
[ 1.348277] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
[ 1.357572] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
[ 1.367734] r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedf1d04 r4:00000000
[ 1.375469] [<c058300c>] (of_platform_bus_create) from [<c058315c>] (of_platform_bus_create+0x150/0x1f0)
[ 1.384938] r10:ee993810 r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedefe1c
[ 1.392754] r4:eedf1d04
[ 1.395289] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
[ 1.404411] r10:00000001 r9:00000000 r8:00000000 r7:c07759d8 r6:00000000 r5:eedee844
[ 1.412228] r4:eedefe1c
[ 1.414769] [<c0583300>] (of_platform_populate) from [<c0a25ee8>] (of_platform_default_populate_init+0x80/0x94)
[ 1.424844] r10:c0a37848 r9:00000000 r8:c0b59680 r7:c0a37834 r6:ffffe000 r5:c0775ce8
[ 1.432661] r4:00000000
[ 1.435200] [<c0a25e68>] (of_platform_default_populate_init) from [<c0102794>] (do_one_initcall+0x5c/0x194)
[ 1.444925] r5:c0a25e68 r4:c0b0a4c8
[ 1.448506] [<c0102738>] (do_one_initcall) from [<c0a00f88>] (kernel_init_freeable+0x1d4/0x268)
[ 1.457195] r9:00000004 r8:c0b59680 r7:c0a37834 r6:c0b59680 r5:c0a47308 r4:c090cfb8
[ 1.464932] [<c0a00db4>] (kernel_init_freeable) from [<c06cf3b0>] (kernel_init+0x10/0x118)
[ 1.473187] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c06cf3a0
[ 1.481004] r4:00000000
[ 1.483540] [<c06cf3a0>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
[ 1.491098] Exception stack(0xee845fb0 to 0xee845ff8)
[ 1.496146] 5fa0: 00000000 00000000 00000000 00000000
[ 1.504313] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.512480] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1.519084] r5:c06cf3a0 r4:00000000
[ 1.522737] ARM CCI_400_r1 PMU driver probed
And only CPU 0 show up.
Regards
^ permalink raw reply
* [PATCH 16/20] ARM: dts: aspeed: Add Witherspoon BMC machine
From: Brandon Wyman @ 2017-12-11 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211050704.20621-17-joel@jms.id.au>
On Sun, Dec 10, 2017 at 11:07 PM, Joel Stanley <joel@jms.id.au> wrote:
> The Witherspoon BMC is an ASPEED ast2500 based BMC that is part of an
> OpenPower Power9 server.
>
> This adds the device tree description for most upstream components. It
> is a squashed commit from the OpenBMC kernel tree.
>
> Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
> Signed-off-by: Matt Spinler <spinler@us.ibm.com>
> Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/Makefile | 4 +-
> arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 547 +++++++++++++++++++++++
> 2 files changed, 550 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5d1e9d37bf3a..15a9207319c1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1104,5 +1104,7 @@ dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
> dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-ast2500-evb.dtb \
> aspeed-bmc-opp-palmetto.dtb \
> - aspeed-bmc-opp-romulus.dtb
> + aspeed-bmc-opp-romulus.dtb \
> + aspeed-bmc-opp-witherspoon.dtb
> +
> endif
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
> new file mode 100644
> index 000000000000..9a0937512e5b
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
> @@ -0,0 +1,547 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +#include "aspeed-g5.dtsi"
> +#include <dt-bindings/leds/leds-pca955x.h>
> +
> +/ {
> + model = "Witherspoon BMC";
> + compatible = "ibm,witherspoon-bmc", "aspeed,ast2500";
> +
> + chosen {
> + stdout-path = &uart5;
> + bootargs = "console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory {
> + reg = <0x80000000 0x20000000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + flash_memory: region at 98000000 {
> + no-map;
> + reg = <0x98000000 0x04000000>; /* 64M */
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <1000>;
> +
> + fan0-presence {
> + label = "fan0-presence";
> + gpios = <&pca0 4 GPIO_ACTIVE_LOW>;
> + linux,code = <4>;
> + };
> +
> + fan1-presence {
> + label = "fan1-presence";
> + gpios = <&pca0 5 GPIO_ACTIVE_LOW>;
> + linux,code = <5>;
> + };
> +
> + fan2-presence {
> + label = "fan2-presence";
> + gpios = <&pca0 6 GPIO_ACTIVE_LOW>;
> + linux,code = <6>;
> + };
> +
> + fan3-presence {
> + label = "fan3-presence";
> + gpios = <&pca0 7 GPIO_ACTIVE_LOW>;
> + linux,code = <7>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fan0 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan1 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 1 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan2 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan3 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + front-fault {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + front-power {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 14 GPIO_ACTIVE_LOW>;
> + };
> +
> + front-id {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 15 GPIO_ACTIVE_LOW>;
> + };
> +
> + rear-fault {
> + gpios = <&gpio ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + rear-id {
> + gpios = <&gpio ASPEED_GPIO(N, 4) GPIO_ACTIVE_LOW>;
> + };
> +
> + rear-power {
> + gpios = <&gpio ASPEED_GPIO(N, 3) GPIO_ACTIVE_LOW>;
> + };
> +
> + power-button {
> + gpios = <&gpio ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + fsi: gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + clock-gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = <&gpio ASPEED_GPIO(E, 0) GPIO_ACTIVE_HIGH>;
> + mux-gpios = <&gpio ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
> + enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
> + trans-gpios = <&gpio ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
> + };
> +
> + iio-hwmon-dps310 {
> + compatible = "iio-hwmon";
> + io-channels = <&dps 0>;
> + };
> +
> + iio-hwmon-bmp280 {
> + compatible = "iio-hwmon";
> + io-channels = <&bmp 1>;
> + };
> +
> +};
> +
> +&fmc {
> + status = "okay";
> +
> + flash at 0 {
> + status = "okay";
> + label = "bmc";
> + m25p,fast-read;
> +#include "openbmc-flash-layout.dtsi"
> + };
> +
> + flash at 1 {
> + status = "okay";
> + label = "alt";
> + m25p,fast-read;
> + };
> +};
> +
> +&spi1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi1_default>;
> +
> + flash at 0 {
> + status = "okay";
> + label = "pnor";
> + m25p,fast-read;
> + };
> +};
> +
> +&uart1 {
> + /* Rear RS-232 connector */
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_txd1_default
> + &pinctrl_rxd1_default
> + &pinctrl_nrts1_default
> + &pinctrl_ndtr1_default
> + &pinctrl_ndsr1_default
> + &pinctrl_ncts1_default
> + &pinctrl_ndcd1_default
> + &pinctrl_nri1_default>;
> +};
> +
> +&uart2 {
> + /* APSS */
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_txd2_default &pinctrl_rxd2_default>;
> +};
> +
> +&uart5 {
> + status = "okay";
> +};
> +
> +&lpc_ctrl {
> + status = "okay";
> + memory-region = <&flash_memory>;
> + flash = <&spi1>;
> +};
> +
> +&mac0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_rmii1_default>;
> + use-ncsi;
> +};
> +
> +&i2c2 {
> + status = "okay";
> +
> + /* MUX ->
> + * Samtec 1
> + * Samtec 2
> + */
> +};
> +
> +&i2c3 {
> + status = "okay";
> +
> + bmp: bmp280 at 77 {
> + compatible = "bosch,bmp280";
> + reg = <0x77>;
> + #io-channel-cells = <1>;
> + };
> +
> + max31785 at 52 {
> + compatible = "maxim,max31785a";
> + reg = <0x52>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + dps: dps310 at 76 {
> + compatible = "infineon,dps310";
> + reg = <0x76>;
> + #io-channel-cells = <0>;
> + };
> +
> + pca0: pca9552 at 60 {
> + compatible = "nxp,pca9552";
> + reg = <0x60>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + gpio at 0 {
> + reg = <0>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 1 {
> + reg = <1>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 2 {
> + reg = <2>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 3 {
> + reg = <3>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 4 {
> + reg = <4>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 5 {
> + reg = <5>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 6 {
> + reg = <6>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 7 {
> + reg = <7>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 8 {
> + reg = <8>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 9 {
> + reg = <9>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 10 {
> + reg = <10>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 11 {
> + reg = <11>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 12 {
> + reg = <12>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 13 {
> + reg = <13>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 14 {
> + reg = <14>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 15 {
> + reg = <15>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + };
> +
> + power-supply at 68 {
> + compatible = "ibm,cffps1";
> + reg = <0x68>;
> + };
> +
> + power-supply at 69 {
> + compatible = "ibm,cffps1";
> + reg = <0x69>;
> + };
> +};
> +
> +&i2c4 {
> + status = "okay";
> +
> + tmp423a at 4c {
> + compatible = "ti,tmp423";
> + reg = <0x4c>;
> + };
> +
> + ir35221 at 70 {
> + compatible = "infineon,ir35221";
> + reg = <0x70>;
> + };
> +
> + ir35221 at 71 {
> + compatible = "infineon,ir35221";
> + reg = <0x71>;
> + };
> +};
> +
> +
> +&i2c5 {
> + status = "okay";
> +
> + tmp423a at 4c {
> + compatible = "ti,tmp423";
> + reg = <0x4c>;
> + };
> +
> + ir35221 at 70 {
> + compatible = "infineon,ir35221";
> + reg = <0x70>;
> + };
> +
> + ir35221 at 71 {
> + compatible = "infineon,ir35221";
> + reg = <0x71>;
> + };
> +};
> +
> +&i2c9 {
> + status = "okay";
> +
> + tmp275 at 4a {
> + compatible = "ti,tmp275";
> + reg = <0x4a>;
> + };
> +};
> +
> +&i2c10 {
> + /* MUX
> + * -> PCIe Slot 3
> + * -> PCIe Slot 4
> + */
> + status = "okay";
> +};
> +
> +&i2c11 {
> + status = "okay";
> +
> + pca9552: pca9552 at 60 {
> + compatible = "nxp,pca9552";
> + reg = <0x60>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + gpio-line-names = "PS_SMBUS_RESET_N", "APSS_RESET_N",
> + "GPU0_TH_OVERT_N_BUFF", "GPU1_TH_OVERT_N_BUFF",
> + "GPU2_TH_OVERT_N_BUFF", "GPU3_TH_OVERT_N_BUFF",
> + "GPU4_TH_OVERT_N_BUFF", "GPU5_TH_OVERT_N_BUFF",
> + "GPU0_PWR_GOOD_BUFF", "GPU1_PWR_GOOD_BUFF",
> + "GPU2_PWR_GOOD_BUFF", "GPU3_PWR_GOOD_BUFF",
> + "GPU4_PWR_GOOD_BUFF", "GPU5_PWR_GOOD_BUFF",
> + "12V_BREAKER_FLT_N", "THROTTLE_UNLATCHED_N";
> +
> + gpio at 0 {
> + reg = <0>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 1 {
> + reg = <1>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 2 {
> + reg = <2>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 3 {
> + reg = <3>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 4 {
> + reg = <4>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 5 {
> + reg = <5>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 6 {
> + reg = <6>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 7 {
> + reg = <7>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 8 {
> + reg = <8>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 9 {
> + reg = <9>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 10 {
> + reg = <10>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 11 {
> + reg = <11>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 12 {
> + reg = <12>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 13 {
> + reg = <13>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 14 {
> + reg = <14>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + gpio at 15 {
> + reg = <15>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + };
> +
> + rtc at 32 {
> + compatible = "epson,rx8900";
> + reg = <0x32>;
> + };
> +
> + eeprom at 51 {
> + compatible = "atmel,24c64";
> + reg = <0x51>;
> + };
> +
> + ucd90160 at 64 {
> + compatible = "ti,ucd90160";
> + reg = <0x64>;
> + };
> +};
> +
> +&i2c12 {
> + status = "okay";
> +};
> +
> +&i2c13 {
> + status = "okay";
> +};
> +
> +&vuart {
> + status = "okay";
> +};
> +
> +&gfx {
> + status = "okay";
> +};
> +
> +&pinctrl {
> + aspeed,external-nodes = <&gfx &lhc>;
> +};
> +
> +&wdt1 {
> + aspeed,reset-type = "none";
> + aspeed,external-signal;
> + aspeed,ext-push-pull;
> + aspeed,ext-active-high;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wdtrst1_default>;
> +};
> --
> 2.14.1
>
Reviewed-by: Brandon Wyman <bjwyman@gmail.com>
^ permalink raw reply
* [RFC] KVM API extensions for SVE
From: Christoffer Dall @ 2017-12-11 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211145135.GK22781@e103592.cambridge.arm.com>
On Mon, Dec 11, 2017 at 02:51:36PM +0000, Dave Martin wrote:
> On Fri, Nov 24, 2017 at 03:45:38PM +0100, Christoffer Dall wrote:
> > On Thu, Nov 23, 2017 at 06:40:50PM +0000, Dave Martin wrote:
> > > On Wed, Nov 22, 2017 at 08:52:30PM +0100, Christoffer Dall wrote:
> > > > Hi Dave,
> > > >
> > > > On Tue, Nov 21, 2017 at 01:49:16PM +0000, Dave Martin wrote:
> > > > > Hi all,
> > > > >
> > > > > SVE adds some new registers, and their size depends on the hardware ando
> > > > > on runtime sysreg settings.
> > > > >
> > > > > Before coding something, I'd like to get people's views on my current
> > > > > approach here.
> > > > >
> > > > > --8<--
> > > > >
> > > > > New vcpu feature flag:
> > > > > /*
> > > > > * userspace can support regs up to at least 2048 bits in size via ioctl,
> > > > > * and will honour the size field in the reg iD
> > > > > */
> > > > > #define KVM_ARM_VCPU_LARGE_REGS 4
> > > > >
> > > > > Should we just error out of userspace fails to set this on a system that
> > > > > supports SVE, or is that too brutal?
> > > >
> > > > That would break older userspace on newer kernels on certain hardware,
> > > > which would certainly not be acceptable. Or did I misunderstand?
> > >
> > > Yes, which is probably bad.
> > >
> > > I'm still trying to gauge the policy regarding backwards compatibility.
> > >
> >
> > Think if QEMU as any other userspace application. We should really
> > never regress userspace.
> >
> > >
> > > So, I guess you're saying is that we should disable SVE for the guest
> > > but still run it in this case.
> > >
> >
> > That's slightly more debatable, but doing it any other way would break
> > any form of migration that relies on the guest configuration of SVE and
> > userspace would have no way to know. I think this sounds like a bad
> > idea.
> >
> > >
> > > This creates another issue: if SVE is supported by the host kernel
> > > but not enabled for the guest, do I need to hist the SVE regs from
> > > KVM_GET_REG_LIST?
> >
> > I don't think so. We should check with QEMU and kvmtool, but I think
> > the way it works is that userspace matches the KVM list with its own
> > internal list, and matches up anything it knows about, and discards the
> > rest. Certainly in the past we haven't been afraid of adding registers
> > to KVM_GET_REG_LIST.
> >
> > >
> > > If not, a guest that doesn't have SVE created on a host that supports
> > > SVE would not be migratable to a host kernel that doesn't support SVE
> > > but otherwise could run the guest: as I understand it, the attempt to
> > > restore the SVE regs on the target node would fail because the host
> > > kernel doesn't recognise those regs.
> > >
> > > Or do we not claim to support backwards compatibility for migration?
> > >
> >
> > I think QEMU and higher level tools like libvirt would have the
> > knowledge to figure this out and implement what they want, so from the
> > kernel's point of view, I think we can simply export the registers when
> > SVE is supported.
> >
> > > >
> > > > > If we do treat that as an error,
> > > > > then we can unconditionally enable SVE for the guest when the host
> > > > > supports it -- which cuts down on unnecessary implementation complexity.
> > > >
> > > > I think it makes sense to be able to disable SVE, especially if there's
> > > > high overhead related to context switching the state. Since you say the
> > > > implementation complexity is unnecessary, I may be missing some larger
> > > > point?
> > >
> > > I don't think it's all that bad, but there doesn't seem to be any
> > > example of an optional architecture feature for a guest today --
> > > so I wanted to check before setting a precedent here.
> >
> > We don't enable the GIC unless userspace asks for it, same with the
> > PMU...
> >
> > >
> > > Would "SVE enabled" be better as an attribute, rather than a
> > > feature, or does it not really matter?
> > >
> >
> > Doesn't matter. It's a question of what you need in terms of the ABI.
> >
> > > > >
> > > > > Alternatively, we would need logic to disable SVE if userspace is too
> > > > > old, i.e., doesn't set this flag. Then we might need to enforce that
> > > > > the flag is set the same on every vcpu -- but from the kernel's PoV
> > > > > it probably doesn't matter.
> > > >
> > > > Not sure I understand why it doesn't matter from the kernel's PoV.
> > > >
> > > > I think SVE should be disabled by default (as it is now) and then we
> > > > should expose a capability (potentially simply via the vcpu attributes
> > > > being present), and let userspace enable SVE and set a vector length.
> > >
> > > Yes, but aren't all the attributes/features per-vcpu?
> > >
> >
> > Yes, so the kernel should check that everything is configured
> > consistently across all VCPUs.
> >
> > > > It makes sense that userspace needs to know about SVE for VMs to use it,
> > > > doesn't it?
> > >
> > > Yes and no. Except for debug purposes I don't see why userspace needs
> > > to know anything execpt how to handle large registers through the ioctl
> > > interface.
> > >
> >
> > Migration is another reason.
> >
> > > > I assume SVE systems will have SVE on all CPUs in an SMP system, or am I
> > > > being way too optimistic about the ARM ecosystem here? Just like we
> > > > don't model big.LITTLE, I think we should enforce in the kernel, that
> > >
> > > The kernel follows the same policy: if SVE is not present on all
> > > physical CPUs we disable it completely and hide it from guests and
> > > userspace.
> > >
> > > For vector length I'm a little more permissive: the max vector length
> > > would be clamped to the minimum commonly supported vector length.
> > >
> >
> > Ok, so KVM could implement the same. Or we could just be reasonable and
> > require userspace to configure all VCPUs the same.
> >
> > > > userspace configures all VCPUs with the same SVE properties.
> > >
> > > OK, so long as you think it's not superfluous to do it, then I'm happy
> > > to do it.
> > >
> > > > >
> > > > > /*
> > > > > * For the SVE regs, we add some new reg IDs.
> > > > > * Zn are presented in 2048-bit slices; Pn, FFR are presented in 256-bit
> > > > > * slices. This is sufficient for only a single slice to be required
> > > > > * per register for SVE, but ensures expansion room in case future arch
> > > > > * versions grow the maximum size.
> > > > > */
> > > >
> > > > I don't understand the last part of this comment?
> > >
> > > This may be explained better in by response below.
> > >
> > > > > #define KVM_REG_SIZE_U2048 (ULL(8) << KVM_REG_SIZE_MASK)
> > > >
> > > > Shift left by KVM_REG_SIZE_MASK? I'm confused.
> > > >
> > > > > #define KVM_REG_ARM64_SVE_Z(n, i) /* Zn[2048 * (i + 1) - 1 : 2048 * i] */ \
> > > > > ((0x0014 << KVM_REG_ARM_COPROC_SHIFT) | KVM_REG_SIZE_U2048 | \
> > > > > ((n) << 5) | (i))
> > > > > #define KVM_REG_ARM64_SVE_P(n, i) /* Pn[256 * (i + 1) - 1 : 256 * i] */ \
> > > > > ((0x0014 << KVM_REG_ARM_COPROC_SHIFT) | KVM_REG_SIZE_U256 | \
> > > > > (((n) + 32) << 5) | (i))
> > > > > #define KVM_REG_ARM64_SVE_FFR(i) /* FFR[256 * (i + 1) - 1 : 256 * i] */ \
> > > > > KVM_REG_ARM64_SVE_P(16, i)
> > > > >
> > > > > For j in [0,3], KVM_REG_ARM64_SVE_Z(n, 0) bits [32(j + 1) - 1 : 32 * j]
> > > > > alias KVM_REG_ARM_CORE_REG(fp_regs.vregs[n]) + j
> > > > >
> > > >
> > > > This is hard to read and understand the way presented here. I would
> > > > suggest you formulate this suggestion in the form of an RFC patch to
> > > > Documentation/virtual/kvm/api.txt plus the header definitions.
> > >
> > > Sure, I hadn't figured out the best way to present this: I was thinking
> > > aloud.
> > >
> > > > (I'm not sure where to look to look to decode the "<< 5" and the
> > > > " + 32) << 5)" stuff above.
> > >
> > > The idea here is that we have 49 registers: Z0-Z31, P0-P15 and FFR.
> > > They are numbered serially.
> > >
> > > However, the SVE architecture leaves the possibility of future
> > > expansion open, up to 32 times the current maximum.
> > >
> > > The KVM reg API doesn't support such ridiculously huge registers,
> > > so my proposal is to slice them up, indexed by the value in the
> > > bottom 5 bits of the reg ID. This requires the "register ID"
> > > field to be shifted up by 5 bits.
> > >
> > > If the regs are not oversized (never, for the current architecture),
> > > then we simply don't list those extra slices via KVM_GET_REG_LIST.
> > >
> > > > > Bits above the max vector length could be
> > > >
> > > > Which bits are these and where are they, and why do we have them?
> > >
> > > The KVM register size via ioctl is fixed at 2048 bits here. Since
> > > the system might not support vectors that large, then bits 2047:1024
> > > in the ioctl payload wouldn't map to any register bits in the hardware.
> > > Should KVM still store them somewhere? Should they logically exist
> > > for the purpose of the ioctl() API?
> > >
> > > Making the size dynamic to avoid surplus bits doesn't work, because KVM
> > > only supports power-of-two reg sizes, whereas SVE can support non-power-
> > > of-two sizes.
> > >
> > > > Is the max vector length the max architecturally (current version)
> > > > defined length, or what is chosen for this VM?
> > >
> > > For now, that's an open question.
> > >
> > > > > * don't care (or not copied at all) on read; ignored on write
> > > > > * zero on read; ignored on write
> > > > > * zero on read; must be zero on write
> > > > >
> > > > > Bits between the current and max vector length are trickier to specify:
> > > > > the "current" vector length for ioctl access is ill-defined, because
> > > > > we would need to specify ordering dependencies between Zn/Pn/FFR access
> > > > > and access to ZCR_EL1.
> > > >
> > > > I think you want userspace to be able to read/write these values in any
> > > > order compared to configuring SVE for the VM, and then fix up whatever
> > > > needs masking etc. in the kernel later, if possible. Ordering
> > > > requirements to userspace accesses have shown to be hard to enforce and
> > > > get right in the past.
> > >
> > > So I've heard from other people.
> > >
> > > > What happens on hardware if you give a certain vector length to EL0, EL0
> > > > writes a value of the full length, and then EL1 restricts the length to
> > > > something smaller, and subsequently expands it again? Is the original
> > > > full value visible or are some bits potentially lost? IOW, can't we
> > > > rely on what the architecture says here?
> > >
> > > The architecture says that bits that are hidden and then revealed again
> > > are either preserved whilst hidden, or zeroed.
> > >
> > > Opinion differs on whether that's a good thing to expose in ABI: Will
> > > considered it unacceptable to expose this kind of behaviour around
> > > syscalls from userspace for example, so I currently always zero the
> > > bits in that case even though it's slightly more expensive.
> > >
> > > The concern here was that userspace might unintentionally rely on
> > > the affected register bits being preserved around syscalls when this
> > > is not guaranteed by the implementation.
> > >
> > > This does not mean that similar design considerations apply to the KVM
> > > ioctl interface though.
> > >
> >
> > It sounds to me that the most simple thing is that the register
> > interface to userspace exposes the full possible register width in both
> > directions, and we apply a mask whenever we need to.
> >
> > > > >
> > > > > So, it may be simpler to expose the full maximum supported vector size
> > > > > unconditionally through ioctl, and pack/unpack as necessary.
> > > >
> > > > yes, I think this was what I tried to say.
> > > >
> > > > >
> > > > > Currently, data is packed in the vcpu struct in a vector length
> > > > > dependent format, since this seems optimal for low-level save/restore,
> > > > > so there will be potential data loss / zero padding when converting.
> > > > >
> > > > > This may cause some unexpected effects. For example:
> > > > >
> > > > > KVM_SET_ONE_REG(ZCR_EL1, 0)
> > > > > /* Guest's current vector length will be 128 bits when started */
> > > > >
> > > > > KVM_SET_ONE_REG(Z0, (uint256_t)1 << 128)
> > > > > KVM_GET_ONE_REG(Z0) /* yields (uint256_t)1 << 128 */
> > > > >
> > > > > KVM_RUN /* reg data packed down to 128-bit in vcpu struct */
> > > > >
> > > > > KVM_GET_ONE_REG(Z0) /* yields 0 even if guest doesn't use SVE */
> > > > >
> > > >
> > > > I really don't know how to parse this or what the point here is? Sorry.
> > >
> > > It means that for the ioctl interface, "obvious" guarantees like "if you
> > > read a register you get back the last value written" don't work quite as
> > > expected. Some bits may have disappeared, or not, depending on the
> > > precise scenario.
> > >
> > > > >
> > > > > Since the guest should be treated mostly as a black box, I'm not sure
> > > > > how big a deal this is. The guest _might_ have explicitly set those
> > > > > bits to 0... who are we to say?
> > > >
> > > > How big a deal what is? I'm lost.
> > > >
> > > > >
> > > > > Can anyone think of a scenario where effects like this would matter?
> > > > >
> > > >
> > > > I think we need more information.
> > >
> > > See if my comments above throw any light on this.
> > >
> >
> > So you're saying even if we try the "expose full width and read back
> > hidden values" approach, those hidden values may be changed when
> > executing the guest, due to the KVM implementation or the way hardware
> > works, is that the point?
>
> Basically yes.
>
> > I think the KVM interface should be designed similarly to being able to
> > probe a hardware CPU's register state at various stages of execution.
> >
> > So, for example, if you write content to hidden bits in the SVE
> > registers from EL2 on real hardware and limit the length using ZCR_EL2,
> > and then run a bunch of code in EL1/0, and then come back to EL2 and
> > examine the registers again, then we should model that behavior in
> > software.
> >
> > In other words, I think we have to model this more closely to what
> > guarantees ZCR_EL2 gives us, and not ZCR_EL1, and choose something
> > architecturally compliant which is reasonable to implement.
>
> So, we imagine that provided the vcpu is not run in the meantime,
> all accesses to SVE regs via the KVM reg API act like they are executed
> at EL2?
Yes, userspace probing virtual EL1 state should be like EL2 probing EL1
state on hardware.
>
> That doesn't seem unreasonable, and it removes any ordering requirement
> between ZCR_EL1 and the SVE regs providing that the vcpu isn't set
> running in the meantime. There is no userspace access to ZCR_EL2 at
> all, if we go with the model of configuring that via attributes that
> must be configured before vcpu startup -- in which case there is no
> ordering requirement there.
>
> The extra bits beyond ZCR_EL1.LEN may disappear as soon as the vcpu
> is run, but that is architecturally consistent behaviour at least.
>
Yes, I think we agree here. It will all be interesting with nested
virtualization where we have to start exposing ZCR_EL2, but that's not
for today.
Thanks,
-Christoffer
^ permalink raw reply
* [kernel-hardening][PATCH] arm: hw_breakpoint: Mark variables as __ro_after_init
From: Kees Cook @ 2017-12-11 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125043.GA17299@pjb1027-Latitude-E5410>
On Mon, Dec 11, 2017 at 4:50 AM, Jinbum Park <jinb.park7@gmail.com> wrote:
> core_num_brps, core_num_wrps, debug_arch, has_ossr,
> max_watchpoint_len are setup once while init stage,
> and never changed after that.
> so it is good candidate for __ro_after_init.
>
> Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
(Probably good to toss this into the ARM patch tracker.)
-Kees
> ---
> arch/arm/kernel/hw_breakpoint.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
> index af2a7f1..629e251 100644
> --- a/arch/arm/kernel/hw_breakpoint.c
> +++ b/arch/arm/kernel/hw_breakpoint.c
> @@ -44,17 +44,17 @@
> static DEFINE_PER_CPU(struct perf_event *, wp_on_reg[ARM_MAX_WRP]);
>
> /* Number of BRP/WRP registers on this CPU. */
> -static int core_num_brps;
> -static int core_num_wrps;
> +static int core_num_brps __ro_after_init;
> +static int core_num_wrps __ro_after_init;
>
> /* Debug architecture version. */
> -static u8 debug_arch;
> +static u8 debug_arch __ro_after_init;
>
> /* Does debug architecture support OS Save and Restore? */
> -static bool has_ossr;
> +static bool has_ossr __ro_after_init;
>
> /* Maximum supported watchpoint length. */
> -static u8 max_watchpoint_len;
> +static u8 max_watchpoint_len __ro_after_init;
>
> #define READ_WB_REG_CASE(OP2, M, VAL) \
> case ((OP2 << 4) + M): \
> --
> 1.9.1
>
--
Kees Cook
Pixel Security
^ 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