| Message ID | 1484832916-7248-1-git-send-email-dingtianhong@huawei.com |
|---|---|
| Headers | show |
| Series | arm64: arch_timer: Add workaround for hisilicon-161010101 erratum | expand |
On 19/01/17 13:35, Ding Tianhong wrote: > Erratum Hisilicon-161010101 says that the ARM generic timer counter "has the > potential to contain an erroneous value when the timer value changes". > Accesses to TVAL (both read and write) are also affected due to the implicit counter > read. Accesses to CVAL are not affected. Please. 3 series in 2 hours is not fun, and is not helping your case either. Give us the time to properly review your patches, and wait until we ask you to respin if we think that this is required. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 19, 2017 at 09:35:12PM +0800, Ding Tianhong wrote: > Ding Tianhong (4): > arm64: arch_timer: Add device tree binding for hisilicon-161010101 > erratum > arm64: arch_timer: Introduce a generic erratum handing mechanism for > fsl-a008585 > arm64: arch_timer: Work around Erratum Hisilicon-161010101 > arm64: arch timer: Add timer erratum property for Hip05-d02 and > Hip06-d03 > > Documentation/admin-guide/kernel-parameters.txt | 9 -- > Documentation/arm64/silicon-errata.txt | 43 +++--- > .../devicetree/bindings/arm/arch_timer.txt | 6 + > arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 + > arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 + > arch/arm64/include/asm/arch_timer.h | 38 ++---- > drivers/clocksource/Kconfig | 18 +++ > drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------ > 8 files changed, 171 insertions(+), 95 deletions(-) I've picked these up (with a few local cleanups), given that some local testing, and pushed the result to a branch [1] on my git repo. There are likely to be clashes with the arm64 tree (e.g. for silicon-errata.txt), and we're also likely to have more arch timer updates shortly for the GTDT stuff, so I think the best bet is for both arm64 and the clocksource tree to pull that branch for v4.11. Alternatively, we could take this all through the arm64 tree, if the clocksource maintainers are happy with that. Thoughts? Thanks, Mark. [1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arch-timer/hisi-161010101 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2017/1/20 23:04, Mark Rutland wrote: > On Thu, Jan 19, 2017 at 09:35:12PM +0800, Ding Tianhong wrote: >> Ding Tianhong (4): >> arm64: arch_timer: Add device tree binding for hisilicon-161010101 >> erratum >> arm64: arch_timer: Introduce a generic erratum handing mechanism for >> fsl-a008585 >> arm64: arch_timer: Work around Erratum Hisilicon-161010101 >> arm64: arch timer: Add timer erratum property for Hip05-d02 and >> Hip06-d03 >> >> Documentation/admin-guide/kernel-parameters.txt | 9 -- >> Documentation/arm64/silicon-errata.txt | 43 +++--- >> .../devicetree/bindings/arm/arch_timer.txt | 6 + >> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 + >> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 + >> arch/arm64/include/asm/arch_timer.h | 38 ++---- >> drivers/clocksource/Kconfig | 18 +++ >> drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------ >> 8 files changed, 171 insertions(+), 95 deletions(-) > > I've picked these up (with a few local cleanups), given that some local > testing, and pushed the result to a branch [1] on my git repo. > > There are likely to be clashes with the arm64 tree (e.g. for > silicon-errata.txt), and we're also likely to have more arch timer > updates shortly for the GTDT stuff, Yes, GTDT patches conflict with this patch set but it's easy to fix. > so I think the best bet is for both > arm64 and the clocksource tree to pull that branch for v4.11. > > Alternatively, we could take this all through the arm64 tree, if the > clocksource maintainers are happy with that. > > Thoughts? GTDT patch set is adding ACPI support for arch timer, and it's only used for ARM64 now, in order to handler the conflict easily, I think take them all through arm64 tree is better (I was working with Fuwei for the GTDT patch set and I hope it's not blocked by "who will merge the code"...) Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23/01/17 07:36, Ding Tianhong wrote: > > > On 2017/1/20 23:04, Mark Rutland wrote: >> On Thu, Jan 19, 2017 at 09:35:12PM +0800, Ding Tianhong wrote: >>> Ding Tianhong (4): >>> arm64: arch_timer: Add device tree binding for hisilicon-161010101 >>> erratum >>> arm64: arch_timer: Introduce a generic erratum handing mechanism for >>> fsl-a008585 >>> arm64: arch_timer: Work around Erratum Hisilicon-161010101 >>> arm64: arch timer: Add timer erratum property for Hip05-d02 and >>> Hip06-d03 >>> >>> Documentation/admin-guide/kernel-parameters.txt | 9 -- >>> Documentation/arm64/silicon-errata.txt | 43 +++--- >>> .../devicetree/bindings/arm/arch_timer.txt | 6 + >>> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 + >>> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 + >>> arch/arm64/include/asm/arch_timer.h | 38 ++---- >>> drivers/clocksource/Kconfig | 18 +++ >>> drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------ >>> 8 files changed, 171 insertions(+), 95 deletions(-) >> >> I've picked these up (with a few local cleanups), given that some local >> testing, and pushed the result to a branch [1] on my git repo. >> >> There are likely to be clashes with the arm64 tree (e.g. for >> silicon-errata.txt), and we're also likely to have more arch timer >> updates shortly for the GTDT stuff, so I think the best bet is for both >> arm64 and the clocksource tree to pull that branch for v4.11. >> >> Alternatively, we could take this all through the arm64 tree, if the >> clocksource maintainers are happy with that. >> >> Thoughts? >> > > Hi Mark: > > It is really a great milestone now, Thanks for the help, and I will > still wait for Marc's new opinion for this version, hoping no need to > change anything else. :) I'm working directly with Mark, and any change I feel necessary will go directly on top of Mark's branch (as far as I'm concerned, these patches are now in a "frozen" state). Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jan 22, 2017 at 03:59:57PM +0800, Hanjun Guo wrote: > On 2017/1/20 23:04, Mark Rutland wrote: > >On Thu, Jan 19, 2017 at 09:35:12PM +0800, Ding Tianhong wrote: > >>Ding Tianhong (4): > >> arm64: arch_timer: Add device tree binding for hisilicon-161010101 > >> erratum > >> arm64: arch_timer: Introduce a generic erratum handing mechanism for > >> fsl-a008585 > >> arm64: arch_timer: Work around Erratum Hisilicon-161010101 > >> arm64: arch timer: Add timer erratum property for Hip05-d02 and > >> Hip06-d03 > >> > >> Documentation/admin-guide/kernel-parameters.txt | 9 -- > >> Documentation/arm64/silicon-errata.txt | 43 +++--- > >> .../devicetree/bindings/arm/arch_timer.txt | 6 + > >> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 + > >> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 + > >> arch/arm64/include/asm/arch_timer.h | 38 ++---- > >> drivers/clocksource/Kconfig | 18 +++ > >> drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------ > >> 8 files changed, 171 insertions(+), 95 deletions(-) > > > >I've picked these up (with a few local cleanups), given that some local > >testing, and pushed the result to a branch [1] on my git repo. > > > >There are likely to be clashes with the arm64 tree (e.g. for > >silicon-errata.txt), and we're also likely to have more arch timer > >updates shortly for the GTDT stuff, > > Yes, GTDT patches conflict with this patch set but it's easy to > fix. Sure. What I meant is that I'd prefer to fix any such conflict myself (i.e. by basing the GTDT patches atop of this), before passing this upwards. > >so I think the best bet is for both arm64 and the clocksource tree to > >pull that branch for v4.11. > > > >Alternatively, we could take this all through the arm64 tree, if the > >clocksource maintainers are happy with that. > > > >Thoughts? > > GTDT patch set is adding ACPI support for arch timer, and it's > only used for ARM64 now, in order to handler the conflict easily, > I think take them all through arm64 tree is better In either case I believe we should be able to handle the conflict. Going through one tree (i.e. arm64) would simplify things substantially, though. This really comes down to what the clocksource maintainers prefer. > (I was working with Fuwei for the GTDT patch set and I hope it's not > blocked by "who will merge the code"...) Hopefully this is just a formality. :) Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 20, 2017 at 03:04:28PM +0000, Mark Rutland wrote: > On Thu, Jan 19, 2017 at 09:35:12PM +0800, Ding Tianhong wrote: > > Ding Tianhong (4): > > arm64: arch_timer: Add device tree binding for hisilicon-161010101 > > erratum > > arm64: arch_timer: Introduce a generic erratum handing mechanism for > > fsl-a008585 > > arm64: arch_timer: Work around Erratum Hisilicon-161010101 > > arm64: arch timer: Add timer erratum property for Hip05-d02 and > > Hip06-d03 > > > > Documentation/admin-guide/kernel-parameters.txt | 9 -- > > Documentation/arm64/silicon-errata.txt | 43 +++--- > > .../devicetree/bindings/arm/arch_timer.txt | 6 + > > arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 + > > arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 + > > arch/arm64/include/asm/arch_timer.h | 38 ++---- > > drivers/clocksource/Kconfig | 18 +++ > > drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------ > > 8 files changed, 171 insertions(+), 95 deletions(-) > > I've picked these up (with a few local cleanups), given that some local > testing, and pushed the result to a branch [1] on my git repo. > > There are likely to be clashes with the arm64 tree (e.g. for > silicon-errata.txt), and we're also likely to have more arch timer > updates shortly for the GTDT stuff, so I think the best bet is for both > arm64 and the clocksource tree to pull that branch for v4.11. > > Alternatively, we could take this all through the arm64 tree, if the > clocksource maintainers are happy with that. Fine by me, but I'd need at least Daniel's ack before taking these. Will -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 24/01/17 15:08, Daniel Lezcano wrote: > On 19/01/2017 14:35, Ding Tianhong wrote: >> Erratum Hisilicon-161010101 says that the ARM generic timer counter "has the >> potential to contain an erroneous value when the timer value changes". >> Accesses to TVAL (both read and write) are also affected due to the implicit counter >> read. Accesses to CVAL are not affected. >> >> The workaround is to reread the system count registers until the value of the second >> read is larger than the first one by less than 32, the system counter can be guaranteed >> not to return wrong value twice by back-to-back read and the error value is always larger >> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL. > > Why not use another clocksource instead of adding a workaround with a > non negligible overhead and more complexity in the code ? The overhead only affects the affected systems, since it is guarded by a static key (the same static key that guards the FSL workaround that is already in mainline). As for creating a different clocksources, this would in turn make the integration with the arch code more complex (arm64 relies on having working architected timers, with or without workarounds) and the integration with KVM (which relies on the same), and in the end create quite a lot of duplication. Are we going to create a separate clocksource for each potential erratum that people with screwed hardware come up with? I'd prefer to organise the mess rather than spread it everywhere. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 24, 2017 at 03:27:51PM +0000, Marc Zyngier wrote: > On 24/01/17 15:08, Daniel Lezcano wrote: > > On 19/01/2017 14:35, Ding Tianhong wrote: > >> Erratum Hisilicon-161010101 says that the ARM generic timer counter "has the > >> potential to contain an erroneous value when the timer value changes". > >> Accesses to TVAL (both read and write) are also affected due to the implicit counter > >> read. Accesses to CVAL are not affected. > >> > >> The workaround is to reread the system count registers until the value of the second > >> read is larger than the first one by less than 32, the system counter can be guaranteed > >> not to return wrong value twice by back-to-back read and the error value is always larger > >> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL. > > > > Why not use another clocksource instead of adding a workaround with a > > non negligible overhead and more complexity in the code ? > > The overhead only affects the affected systems, since it is guarded by a > static key (the same static key that guards the FSL workaround that is > already in mainline). Yes, that is what I understood so far. > As for creating a different clocksources, this would in turn make the > integration with the arch code more complex (arm64 relies on having > working architected timers, with or without workarounds) and the > integration with KVM (which relies on the same), and in the end create > quite a lot of duplication. Are we going to create a separate > clocksource for each potential erratum that people with screwed hardware > come up with? That wasn't my point. The way the errata are handled in this patchset is elegant and I have nothing against it. I'm worried about the accumulation of fixes, hacks, workarounds in this driver. So my naive question is about not using an identified bogus clocksource and use another one available on the board, which is I believe often the case, instead of trying to deal with bogus hardware. Apparently, that is not possible because 1) of KVM, 2) of duplication and 3) of integration with the ARM64 code. Does it mean it is not possible to use another clocksource/clockevent than the armv8-timer ? Can you elaborate these three points ? > I'd prefer to organise the mess rather than spread it everywhere. I will add this punchline to my fortune database :) -- Daniel -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Daniel, On Tue, Jan 24, 2017 at 05:35:51PM +0100, Daniel Lezcano wrote: > That wasn't my point. The way the errata are handled in this patchset is > elegant and I have nothing against it. I'm worried about the accumulation of > fixes, hacks, workarounds in this driver. So my naive question is about not > using an identified bogus clocksource and use another one available on the > board, which is I believe often the case, instead of trying to deal with bogus > hardware. Apparently, that is not possible because 1) of KVM, 2) of duplication > and 3) of integration with the ARM64 code. > > Does it mean it is not possible to use another clocksource/clockevent than the > armv8-timer ? > > Can you elaborate these three points ? Practically speaking, these platforms have no other clocksource or clockevent device that I am aware of, which can be enumerated in a standard manner using ACPI. For point 1, KVM is intimately familiar with the architected timer (which is managed during VM context switch in hyp code, for example). KVM knows nothing of other clocksource or clockevent devices, and it is far from trivial to plumb these in either way. Since the architected timer is a mandatory part of ARMv8, guests may attempt to use it regardless. For point 3, arm64 currently requires the architected timer as this is mandatory per the ARMv8 architecture. It is non-trivial to add support for other devices to the vDSO, the delay loop, etc. Localising these quirks to the architected timer driver is by far the least worst option available. Marc and I are perfectly happy to manage that. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 30, 2017 at 03:52:09PM +0000, Mark Rutland wrote: > Hi Daniel, > > On Tue, Jan 24, 2017 at 05:35:51PM +0100, Daniel Lezcano wrote: > > That wasn't my point. The way the errata are handled in this patchset is > > elegant and I have nothing against it. I'm worried about the accumulation of > > fixes, hacks, workarounds in this driver. So my naive question is about not > > using an identified bogus clocksource and use another one available on the > > board, which is I believe often the case, instead of trying to deal with bogus > > hardware. Apparently, that is not possible because 1) of KVM, 2) of duplication > > and 3) of integration with the ARM64 code. > > > > Does it mean it is not possible to use another clocksource/clockevent than the > > armv8-timer ? > > > > Can you elaborate these three points ? > > Practically speaking, these platforms have no other clocksource or > clockevent device that I am aware of, which can be enumerated in a > standard manner using ACPI. > > For point 1, KVM is intimately familiar with the architected timer > (which is managed during VM context switch in hyp code, for example). > KVM knows nothing of other clocksource or clockevent devices, and it is > far from trivial to plumb these in either way. Since the architected > timer is a mandatory part of ARMv8, guests may attempt to use it > regardless. > > For point 3, arm64 currently requires the architected timer as this is > mandatory per the ARMv8 architecture. It is non-trivial to add support > for other devices to the vDSO, the delay loop, etc. Ok, thanks for these clarifications. > Localising these quirks to the architected timer driver is by far the > least worst option available. Marc and I are perfectly happy to manage > that. It is up to me to ensure the clockevent/clocksource drivers in general are following the right direction. And this driver looks more and more opaque. I will spend some times to do a review of the driver as soon as I have time. So we finish the reviews of this series, you take the patches when I ack them up, but from this point, any submission for this driver will have to stick to the standard submission rules, that is to say: Thomas Gleixner and I have to be recipients of the patches and go through our tree. Dependency issues with other patchset must be solved before applying them in another tree. Thanks. -- Daniel -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 19, 2017 at 09:35:15PM +0800, Ding Tianhong wrote: > Erratum Hisilicon-161010101 says that the ARM generic timer counter "has the > potential to contain an erroneous value when the timer value changes". > Accesses to TVAL (both read and write) are also affected due to the implicit counter > read. Accesses to CVAL are not affected. > > The workaround is to reread the system count registers until the value of the second > read is larger than the first one by less than 32, the system counter can be guaranteed > not to return wrong value twice by back-to-back read and the error value is always larger > than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL. > > The hisilicon erratum CONFIG name is too long, breaking the line format in silicon-errata.txt, > so extended the character spacing to fit all the erratum config. Line length. > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > --- > Documentation/arm64/silicon-errata.txt | 43 ++++++++++++++--------------- > drivers/clocksource/Kconfig | 12 ++++++++- > drivers/clocksource/arm_arch_timer.c | 49 ++++++++++++++++++++++++++++++++++ > 3 files changed, 82 insertions(+), 22 deletions(-) > > diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt > index 405da11..0aaae35 100644 > --- a/Documentation/arm64/silicon-errata.txt > +++ b/Documentation/arm64/silicon-errata.txt > @@ -42,24 +42,25 @@ file acts as a registry of software workarounds in the Linux Kernel and > will be updated when new workarounds are committed and backported to > stable kernels. > > -| Implementor | Component | Erratum ID | Kconfig | > -+----------------+-----------------+-----------------+-------------------------+ > -| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | > -| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | > -| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | > -| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 | > -| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 | > -| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | > -| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | > -| ARM | Cortex-A57 | #852523 | N/A | > -| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | > -| ARM | Cortex-A72 | #853709 | N/A | > -| ARM | MMU-500 | #841119,#826419 | N/A | > -| | | | | > -| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 | > -| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 | > -| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | > -| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 | > -| Cavium | ThunderX SMMUv2 | #27704 | N/A | > -| | | | | > -| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | > +| Implementor | Component | Erratum ID | Kconfig | > ++----------------+-----------------+-----------------+---------------------------------+ > +| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | > +| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | > +| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | > +| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 | > +| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 | > +| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | > +| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | > +| ARM | Cortex-A57 | #852523 | N/A | > +| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | > +| ARM | Cortex-A72 | #853709 | N/A | > +| ARM | MMU-500 | #841119,#826419 | N/A | > +| | | | | > +| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 | > +| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 | > +| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | > +| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 | > +| Cavium | ThunderX SMMUv2 | #27704 | N/A | > +| | | | | > +| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | > +| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 | > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig > index 6693e07..b30f44f 100644 > --- a/drivers/clocksource/Kconfig > +++ b/drivers/clocksource/Kconfig > @@ -327,7 +327,7 @@ config ARM_ARCH_TIMER_EVTSTREAM > > config ARM_ARCH_TIMER_OOL_WORKAROUND > bool > - depends on FSL_ERRATUM_A008585 > + depends on FSL_ERRATUM_A008585 || HISILICON_ERRATUM_161010101 Same comment as the previous patch, this dependency is pointless. Isn't possible to rely on the __init data mechanism, instead of polluting the Kconfig with more options ? > help > This option would only be enabled by Freescale/NXP Erratum A-008585 > or something else chip has similar erratum. > @@ -343,6 +343,16 @@ config FSL_ERRATUM_A008585 > value"). The workaround will only be active if the > fsl,erratum-a008585 property is found in the timer node. > > +config HISILICON_ERRATUM_161010101 > + bool "Workaround for Hisilicon Erratum 161010101" > + default y > + select ARM_ARCH_TIMER_OOL_WORKAROUND > + depends on ARM_ARCH_TIMER && ARM64 > + help > + This option enables a workaround for Hisilicon Erratum > + 161010101. The workaround will be active if the hisilicon,erratum-161010101 > + property is found in the timer node. > config ARM_GLOBAL_TIMER > bool "Support for the ARM global timer" if COMPILE_TEST > select CLKSRC_OF if OF > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c > index 2487c66..7451b62 100644 > --- a/drivers/clocksource/arm_arch_timer.c > +++ b/drivers/clocksource/arm_arch_timer.c > @@ -131,6 +131,47 @@ static u64 notrace fsl_a008585_read_cntvct_el0(void) > } > #endif > > +#ifdef CONFIG_HISILICON_ERRATUM_161010101 > +/* > + * Verify whether the value of the second read is larger than the first by > + * less than 32 is the only way to confirm the value is correct, so clear the > + * lower 5 bits to check whether the difference is greater than 32 or not. > + * Theoretically the erratum should not occur more than twice in succession > + * when reading the system counter, but it is possible that some interrupts > + * may lead to more than twice read errors, triggering the warning, so setting > + * the number of retries far beyond the number of iterations the loop has been > + * observed to take. > + */ > +#define __hisi_161010101_read_reg(reg) ({ \ > + u64 _old, _new; \ > + int _retries = 50; \ > + \ > + do { \ > + _old = read_sysreg(reg); \ > + _new = read_sysreg(reg); \ > + _retries--; \ > + } while (unlikely((_new - _old) >> 5) && _retries); \ > + \ > + WARN_ON_ONCE(!_retries); \ > + _new; \ > +}) > + > +static u32 notrace hisi_161010101_read_cntp_tval_el0(void) > +{ > + return __hisi_161010101_read_reg(cntp_tval_el0); > +} > + > +static u32 notrace hisi_161010101_read_cntv_tval_el0(void) > +{ > + return __hisi_161010101_read_reg(cntv_tval_el0); > +} > + > +static u64 notrace hisi_161010101_read_cntvct_el0(void) > +{ > + return __hisi_161010101_read_reg(cntvct_el0); > +} > +#endif > + > #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND > const struct arch_timer_erratum_workaround *timer_unstable_counter_workaround = NULL; > EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround); > @@ -147,6 +188,14 @@ static u64 notrace fsl_a008585_read_cntvct_el0(void) > .read_cntvct_el0 = fsl_a008585_read_cntvct_el0, > }, > #endif > +#ifdef CONFIG_HISILICON_ERRATUM_161010101 > + { > + .id = "hisilicon,erratum-161010101", > + .read_cntp_tval_el0 = hisi_161010101_read_cntp_tval_el0, > + .read_cntv_tval_el0 = hisi_161010101_read_cntv_tval_el0, > + .read_cntvct_el0 = hisi_161010101_read_cntvct_el0, > + }, > +#endif > }; > #endif /* CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND */ > > -- > 1.9.0 > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 30, 2017 at 10:54:30PM +0100, Daniel Lezcano wrote: > On Mon, Jan 30, 2017 at 03:52:09PM +0000, Mark Rutland wrote: > > Hi Daniel, > > > > On Tue, Jan 24, 2017 at 05:35:51PM +0100, Daniel Lezcano wrote: > It is up to me to ensure the clockevent/clocksource drivers in general are > following the right direction. And this driver looks more and more opaque. I > will spend some times to do a review of the driver as soon as I have time. FWIW, I'd locally fixed up the patches in the branch I previously mentioned, so many issues in this series no longer exist. I will post the cleaned up series momentarily. Hopefully that should be less painful to review. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Erratum Hisilicon-161010101 says that the ARM generic timer counter "has the potential to contain an erroneous value when the timer value changes". Accesses to TVAL (both read and write) are also affected due to the implicit counter read. Accesses to CVAL are not affected. The workaround is to reread the system count registers until the value of the second read is larger than the first one by less than 32, the system counter can be guaranteed not to return wrong value twice by back-to-back read and the error value is always larger than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL. v2: Introducing a new generic erratum handling mechanism for fsl,a008585 and hisilicon,161601. Significant rework based on feedback, including seperate the fsl erratum a008585 to another patch, update the erratum name and remove unwanted code. v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585 and make the #define __fsl_a008585_read_reg to be private to the .c file instead of being globally visible. After discussion with Marc and Will, a consensus decision was made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum, and make some generic name more specific, export timer_unstable_counter_workaround for module access. Significant rework based on feedback, including fix some alignment problem, make the #define __hisi_161601_read_reg to be private to the .c file instead of being globally visible, add more accurate annotation and modify a bit of logical format to enable arch_timer_read_ool_enabled, remove the kernel commandline parameter clocksource.arm_arch_timer.hisilicon-161601. Introduce a generic aquick framework for erratum in ACPI mode. v4: rename the quirk handler parameter to make it more generic, and avoid break loop when handling the quirk becasue it need to support multi quirks handler. update some data structures for acpi mode. v5: Adapt the new kernel-parameters.txt for latest kernel version. Set the retries of reread system counter to 50, because it is possible that some interrupts may lead to more than twice read errors and break the loop, it will trigger the warning, so we set the number of retries far beyond the number of iterations the loop has been observed to take. v6: The last 2 patches in the previous version about the ACPI mode will conflict witch Fuwei's GTDT patches, so remove the ACPI part and only support the DT base code for this patch set. We have trigger a bug when select the CONFIG_FUNCTION_GRAPH_TRACER and enable function_graph to /sys/kernel/debug/tracing/current_tracer, the system will stall into an endless loop, it looks like that the ftrace_graph_caller will be related to xxx.read_cntvct_el0 and read the system counter again, so mark the xxx.read_cntvct_el0 with notrace to fix the problem. v7: Introduce a new general config symbol named CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND to enable the workaround for any chips which has similar arch timer erratum just like "fsl,erratum_a008585" and "hisilicon,erratum_161601", modify the struct arch_timer_erratum_workaround to be compatible different chip erratum more easily, and reconstruction some code base on the new config symbol and struct, thanks to Marc's suggestion. v8: The original erratum ID could not cover all modules, which only specified <Errata-Prefix><SerialNum>, so after discussion with the soc team, we decide to use the new ID "161010101" for this timer erratum which consist of <Errata-Prefix><SeriesFlag><ModuleID><SerialNum> and also update the hisilicon erratum official documents. v9: Modify the workaround description and remove the message for CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND. Ding Tianhong (4): arm64: arch_timer: Add device tree binding for hisilicon-161010101 erratum arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585 arm64: arch_timer: Work around Erratum Hisilicon-161010101 arm64: arch timer: Add timer erratum property for Hip05-d02 and Hip06-d03 Documentation/admin-guide/kernel-parameters.txt | 9 -- Documentation/arm64/silicon-errata.txt | 43 +++--- .../devicetree/bindings/arm/arch_timer.txt | 6 + arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 + arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 + arch/arm64/include/asm/arch_timer.h | 38 ++---- drivers/clocksource/Kconfig | 18 +++ drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------ 8 files changed, 171 insertions(+), 95 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html